🏠 back to Observable

Login for the currentUser and team

I have a neat way of securely authenticating the current user that does not require an Oauth client.

Comments contain the username of the speaker, so we can use that to bootstrap a secure login system.


lol this is wild. very cool


I have upgraded this notebook so it’s suitable federated login.

I have created a custom set of endpoints for federated authentication of endpointservices Firebase here, which is basically some minor configuration over the login-with-comment notebook

The endpoint-login-with-comment enables “A creator owns their own data and the right to programmatically access their data, but not other creator’s data”. It keeps forkability of notebooks to a degree. How this plays out:

Anybody can login to @endpointservices, and get a token for use with endpointservice APIs (e.g. @endpointservices/secrets is for use with anybody). This is secure because I put in access controls that enforce user isolation, and nobody but me can tamper with those notebooks.

On top of this I allow Toph to fork @endpointservices/secrets, and he should still be able to access Toph’s secrets from @Toph notebooks. Said another way, Toph can generate a Toph access token using endpoint-login-with-comment from the toph content domain. So Toph is free to manage his secrets programatically in his own namespace.

A different person, e.g. tomlarkworthy, can login using @endpointservices and access their secrets. However, if tomlarkworthy tried to use Toph’s login page hosted on @toph, no access token will be issued. This is to avoid the situation where Toph has booby trapped a page, steals a token, and does some random stuff that is unwanted.

This creators can access their own data federated security logic is encoded in the AUTH_CHECK Endpoint Login with Comment / Endpoint Services / Observable

So this is fairly easy for others to do in my opinion. If you create your own Firebase account you just need to fill in the details like in @endpointservices/endpoint-login-with-comment and you have your own federated auth server for persistence of data and other such things and you can offer programmable services to others in the community securely. They will even be able to fork notebooks and still use your services from their own notebooks.

1 Like

More upgrades: Team Support.

Now there is an option to scan observable profiles for team membership. These are exposed as JWT custom claims, allowing you to gate access to backend services based on team membership.

So we could allow read and write access to docs to just team members of the same name with the following rule:-

match /teamdocs/{teamdoc} {
    allow read, write: if request.auth.token['observablehq.com'][teamdoc] == 'admin';

If the scan for teams feature is checked during login, the verifier will look for cross-linked observablehq profile accounts stemming from the user’s profile.

For example, say we want @tomlarkworthy to administer @endpointservices, then

(note the cross linking is the mechanism behind relmeauth)

1 Like