How to use connection refresh tokens

Authress provider login aggregation, and it makes federated login easier. It does this by creating optimized user access tokens to be used and verified by service APIs. Authress creates access tokens specifically for your application.

Credentials Vault

Authress is also able to connect with any registered provider configured as an Authress OAuth Connection. If a connection is enabled with a refresh token, or other long lived access token. Then this token can be optionally stored in Authress and be available when the user or a service client you control requests it.

When an access token is requested from the connection’s credentials vault, Authress determines if the current available token will still be valid for a sufficient length of time, and if not will automatically use the refresh token to generate a new access token. It does this using the OAuth configuration in the connection, and without ever revealing the refresh token at any time.

Setup

The critical step is to configure the federated login provider to return long lived refresh tokens. This is usually done via the connectionProperties on authentication. For the Google OAuth connection provider, refresh tokens are generated when the access_type property is configured to be offline. Additionally, Google may not always return the necessary refresh token, in these cases, be sure to follow closely the Google login OAuth client setup and use the following connectionProperties as strictly documented here:

Client side access

After a user logs in with their selected OAuth identity provider and is redirected through Authress back to your application UI, there is an opportunity to exchange the Authress JWT for the provider credential. If the UI decides to interact with the provider’s API directly in the browser, the Authress Login SDK can be used to fetch the provider access token:

Service side access

Alternatively, requests may want to be made async from the service side, even when the user isn’t logged in. There may be relevant background tasks that need to be performed, or long running actions. (Here are examples of long running transaction architecture in case one of those patterns better matches the use case).

In this circumstance, the context is the service client. Since the credentials are saved in the Authress connection vault, if the service has access to make requests to the connection’s credential value: connections:credentials:read to the relevant: Authress:Connections/${connectionId}/Users/${userId}/Credentials, then the service client can access the credentials for the user.

Additional resources

Take a look at the full API documentation to see what else is possible.

Didn't find what you were looking for?

Or send us an email at support@authress.io