[RFC] Authentication and Authorization #1
andrewmd5
announced in
RFC / Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Within this post you'll find an overview of the abstraction Tempo provides to handle authentication (verifying the identity of a peer or service) and authorization (determines their access rights.)
Setting Credentials
If your API requires user authentication, it is crucial to provide a way to assign user credentials for subsequent requests to a Tempo server. The
ServerContextinstance, passed into each service method implementation, exposes a method calledsetOutgoingCredentials.Credentials are defined as:
For example, if you're using JWT for authorization in your API, you could sign the token and supply it to
setOutgoingCredentialsas follows:When the response is sent to a client, the
Credentialsare serialized and set on thetempo-credentialsheader. The client stores the credentials if configured to do so.It's also possible to extend the interface, allowing you to build additional functionality based on the concept of
Credentials:Intercepting Credentials
The
@tempojs/serverpackage also exposes anAuthInterceptorabstract class, which can be implemented and passed into the constructor of a router. The purpose ofAuthInterceptoris to allow your code to inspect a request with itsAuthorizationheader set so you can perform validation and populate anAuthContextthat will be forwarded to service methods. Below is an example implementation ofAuthInterceptorthat verifies a JWT and authenticates a peer:To clarify a few points:
AuthContextis a collection of properties relevant to the context of a request. Importantly, when you setsetPeerIdentityPropertyName, you're indicating that the peer, and by extension theAuthContext, is authenticated.In the example above, we're not throwing an error - this is because an empty
AuthContextwill always be unauthenticated, so it is still safe to pass to a method that requires authentication, provided you check that theAuthContextis authenticated. You can throw aTempoError(TempoStatusCode.Unauthenticated)ininterceptif you want (and it will propagate back to the client), however, we recommend throwing in the method that requires an authenticated context instead, so you don't become reliant on a middleware pattern.Storing Credentials
At this time, Tempo does not support setting cookies (or any custom response headers), nor does it expose a way of accessing them through the abstraction short of manually parsing incoming headers. As such, the
@tempojs/clientpackage exposes an abstraction to allow clients to store credentials received via thetempo-credentialsheader so they can automatically be put on request:These strategies are used on implementations of
CallCredentials:You can, of course, implement a custom
CallCredentialsto fit your use-case:Then, when creating a channel, you supply the
CallCredentialsimplementation:When you make a call to a remote method that sets credentials, the client will now store them automatically:
Questions for You
All reactions