I am using LWA to create an application, There are several micro services that can call my auth service. I want to prevent 2 services from having access token collision.
So, assume service A calls auth service with refresh token 'xyz' and gets an access token.
Now, service B invokes auth service with refresh token 'xyz' and gets another access token.
since refresh token lives indefinitely I am finding it hard to securely prevent collision for access token.
The auth service should be keeping track of the tokens issued. In case of corruption, the auth service can invalidate the associated tokens. If you do, then you can do a simple check against this list and retry.
Refresh tokens should roll after getting used, i.e., you should generate a fresh refresh token when one is exchanged for an access token. Refresh tokens should not live indefinitely.
Related
I have a web service that makes use of the Authorization Code grant type to get an Access Token for user data on a Resource Server, together with a Refresh Token. Now my web service launches jobs at certain points in time that should also access this user data. However,
there may be more than one job running at a time,
the user is not necessarily around when the jobs are spawned, and
the jobs may be long-running, in particular they may live longer than the validity of the Access Token.
My question is: How can I provide each job with an Access Token so that
no user interaction is required for every single job launch, and
each job can refresh its own Access Token if necessary, without invalidating other jobs' tokens?
While https://datatracker.ietf.org/doc/html/rfc6749#section-1.5 states that a refresh token can be used to obtain "additional access tokens" (emphasis mine), the spec is not so clear on whether the previous Access Token remains valid until it's expiry date (well, if it does not I wouldn't call it "additional"). Also, according to https://datatracker.ietf.org/doc/html/rfc6749#section-6 if a server issues a new Refresh Token to prevent replay attacks, then the old Refresh Token cannot be used any more, so now maybe I have an additional Access Token, but I can't really pass the Access Token and the new Refresh Token to the job, because if the job made use of that Refresh Token would then my web service couldn't use it any more.
Are there maybe any lesser-known flows that allow for this kind of unattended Access Token creation?
Normally access tokens and refresh tokens are valid till the exipration time.
Having multiple access and refresh tokens are also allowed.
However a refresh token can be revoked under following scenarios
the authorization server has revoked the refresh token
the user has revoked their consent for authorization
the refresh token has expired
the authentication policy for the resource has changed
Since you are having the background jobs running. I suggest not to use JWT Tokens for authentication. Instead you can have your custom security standards.
Like custom API Key, UserAgent for Jobs and you can pass the user information with the requset or as custom-header as well.
I'm working on a web application that will be installed on-prem behind Azure App Proxy. I can authenticate with OAuth and access the app successfully, but the authentication token is only good for an hour, after which my application is kind of dead because none of its API calls make it through the proxy.
So I'd like a way to keep that access alive so that users don't have to re-authenticate every hour.
I know that there's a flow for exchanging a refresh token for a new access token, and I can do that. But it seems like the ability to pass through the proxy is not governed directly by that token, but by a cookie called AzureAppProxyAccessCookie. Since I don't know how to convert my refreshed access token to a valid cookie value, this doesn't seem to solve my problem.
Note that I don't manage the proxy, so just increasing the expiration time on the token issued by Azure isn't an option.
So is there a way to refresh the AzureAppProxyAccessCookie token, or otherwise keep the session alive without making the user re-authenticate?
You can define a token life time policy with a longer token lifetime and assign it to your application.
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-configurable-token-lifetimes#access-id-and-saml2-token-lifetime-policy-properties
https://learn.microsoft.com/en-us/azure/active-directory/develop/configure-token-lifetimes#create-a-policy-for-web-sign-in
I'm creating an app that integrates with several 3rd-party Oauth2 providers (think Zapier). The user adds a connection through Oauth2 which gives me a refresh token and access token and which I'm storing in a database.
What is the best practice to keep the access token fresh? Should I be running an async job (e.g. cron) that refreshes the access token every 30 minutes for every connection? If the user doesn't use my app for several days I'd like to still be able to access his 3rd-party data without having him to go through the Oauth2 consent.
What is the best practice to keep the access token fresh? Should I be running an async job (e.g. cron) that refreshes the access token every 30 minutes for every connection?
Not necessarily. Wait till your API call fails. Check for a proper response such as "401 Unauthorized" which hints your access token is invalidated/expired. Once this happens use refresh token to renew the access token. If refresh token fails, then you have to fall back again and ask user to login again.
A refresh token can have a varying life time. It can be from few days to few months. For example check Google's explanation mentioning long lived refresh tokens and possible expiry of them. Also check how Azure AD mention about configurations related to token lifetimes.
So user not using app for few days (ex:- leave it and return after weekend) can be handled through proper validity configurations of tokens lifetimes. But be mindful about threats that could occur from long-lived, unmanaged tokens (ex:- due to token stealing).
The Oauth website has a pretty informative answer
The “expires_in” value is the number of seconds that the access token
will be valid. It’s up to the service you’re using to decide how long
access tokens will be valid, and may depend on the application or the
organization’s own policies. You could use this timestamp to
preemptively refresh your access tokens instead of waiting for a
request with an expired token to fail. Some people like to get a new
access token shortly before the current one will expire in order to
save an HTTP request of an API call failing. While that is a perfectly
fine optimization, it doesn’t stop you from still needing to handle
the case where an API call fails if an access token expires before the
expected time. Access tokens can expire for many reasons, such as the
user revoking an app, or if the authorization server expires all
tokens when a user changes their password.
If you make an API request and the token has expired already, you’ll
get back a response indicating as such. You can check for this
specific error message, and then refresh the token and try the request
again.
TLDR: I would only refresh the token when a request fails
I'm working on a SPA app based on Node, with token-based authentication using JWT. Right now, the jwt token never expires, which is not good.
I want it to expire for more security, but I don't want my users to be forced to re-log. That's why I need a refresh token.
So i'm reading about OAuth2.
I have a hard-time to understand why refresh-tokens must be stored in a database, whereas access-token are generated on the fly using a secret key.
Why refresh tokens can't be generated the same way as access tokens ?
Thank you guys !
Refresh tokens usually are generated the same way as access tokens.
An authorization server will often return a refresh and access token if requested (and you're not using the implicit grant type).
The difference is how they are used.
An access-token is usually a bearer token: whoever has it can use it against the resource server, but it is only valid for a short period of time. In which case, storing them in a database is often pointless as they are worthless once expired.
A refresh token however is like having access to a "forge" which allows you to mint a new token.
If you present the refresh token to the authorisation server (not the resource server) you will get back a new access token and possibly a new refresh token.
Providing of course that the user has not revoked/changed access permissions to your application and that the user is still a valid user.
So you would keep them in a database perhaps because your user logs in infrequently. So you may need the refresh token weeks after you got it.
Alternative to the refresh token.
If you are using the implicit grant (which is common with SPAs but not recommended). You can try and keep your end user logged in to the identity provider used by the authorisation server. This way you can keep requesting new access tokens from the auth server without the user being prompted by the auth server for credentials as a session will be persisted between the identity provider and the user's browser.
maybe i'm misunderstanding the authorization code grant type, but i thought that after issuing a code spring will keep the code in oauth_code table in DB forever till it will be revoked by user , but the code is deleted right after it is consumed (first time you exchange this for token),
so what is the flow here - should my clients keep the refresh tokens for getting access token later on (or when user is offline)
the spec say the return of refresh tokens is optional as written
The authorization server authenticates the client, validates the
authorization code, and ensures that the redirection URI
received matches the URI used to redirect the client in
step (C). If valid, the authorization server responds back with
an access token and, optionally, a refresh token.
so it the authorization server decide not to give refresh token there is no way for clients to offline request access token and they need to go though the authorization code process all over again ?
thanks
Shlomi
The authorization code can only be used once, and it must have a short lifetime. If you read section 4.1.2 of the spec it says
The authorization code MUST expire
shortly after it is issued to mitigate the risk of leaks. A
maximum authorization code lifetime of 10 minutes is
RECOMMENDED.
So once a code has been used there is not real reason to retain it (other than possibly to detect further attempts to use it).
The refresh token allows the client to obtain another access token. Otherwise, as you say, it needs to re-execute the authorization code flow to get one from scratch, which requires the interaction of the resource owner (the user). Usually the system would be set up to issue a refresh token or not to that client depending on whether it actually requires offline access to the resource, or whether the resource owner (user) will always be interating with it directly.