Is it possible to "reduce" scopes in OAuth? Scope reduction should be initiated by the client.
Meaning: Request a new Access Token using the Refresh Token, but the new token has less scopes than the "original" one?
Use case: I'm developing a client application that authenticates users via OAuth with another party (A). Now I want to give yet another party (B) access to some scopes, but less than I have.
Unfortunately there's no standard way to do what you want, but even if there were, you can't often get a new access token without destroying the old access token.
Access tokens are per-client. Once it expires, you can use a refresh token to get a new access token, but many systems are implemented in a way that a refresh token can only be used once and that the original access token immediately (or quickly) expires.
If you control the server, it's definitely possible to implement this as a new, custom grant type, effectively an extension of OAuth2.
According to https://www.rfc-editor.org/rfc/rfc6749#section-6 you should be able to add a scope field on a refresh request, as long as your requested scopes are a subset of the originals and your refresh token is still valid.
Note that the reduced scopes only apply to the access token, so if you leak a long lived refresh token to a third party they can get all the scopes it had.
Related
Per Google's docs it would seem refresh tokens are only necessary for offline applications (applications that may run into an expired access token when the user isn't around).
Access tokens periodically expire. You can refresh an access token
without prompting the user for permission (including when the user is
not present) if you requested offline access to the scopes associated
with the token.
...
Requesting offline access is a requirement for any application that
needs to access a Google API when the user is not present. For
example, an app that performs backup services or executes actions at
predetermined times needs to be able to refresh its access token when
the user is not present. The default style of access is called online.
However, a description of refresh tokens in general and this question in particular both seem to imply that refresh tokens are needed anytime you want to request a new access token.
I think I would agree with Google's explanation and not use refresh tokens. My experience with OIDC providers has been that refresh works as follows:
User requests protected resource from client server
Client server determines access token has expired.
Client server redirects user to OP auth endpoint
OP authenticates user without interaction due to cookies stored on user's browser with OP's domain.
Client server finishes the request.
The user might see a few redirects but other than that the re-authentication went by without any interaction from them. Given this, is it necessary to bother with refresh tokens if the user will always be present at the application?
My biggest concern with using refresh tokens for online apps is that it takes away transparency from the user.
Refresh tokens facilitate long term access and should be stored safely. But they also don't provide a natural way to "sign out", and (most importantly) it becomes completely opaque how, when and from where your data is accessed, as the often used scope name offline_access suggests.
OIDC offers a front channel mechanism prompt=none that largely leads to the same effect (i.e. new tokens), and without needing intermediate redirects if the re-authentication is performed inside an iframe.
Hence in my opinion you and Google are right and the answer must be: No, don't use refresh tokens if the user is present.
No, it is not necessary to bother with refresh tokens if the user will always be present at the application. The reasoning is largely the OP describes.
But there are reasons why one may still want a refresh token:
as the OP mentions the user might see a few redirects and both the UI expert and the branding guy on your team will hate this
when an access token expires in the middle of an HTML Form POST action, the redirect may have lost the context/POST-data on return; you may want to minimize this or you'll have to take appropriate (complex) POST-data-save actions
if your access token expiry is really short, the redirects create a lot of overhead and nuisance; you may not be able to control access token expiry when dealing a Providers in a different domain and when dealing with multiple Providers it will vary across them
when refreshing the access token with a redirect your application now depends on the Provider keeping an SSO session; not all Providers may do this and if they do they may do it in different ways: the SSO session duration may vary between them and the authentication method may vary; as an example: a Provider that doesn't keep an SSO session but does use 2-factor authentication will have large impact on the user experience
Imagine a scenario where you want to use the access token to update user information in almost real-time from the user info endpoint but the access token expiry is relatively short. Either you'll have to perform a lot of redirects with the nuisance as described, or you can use a refresh token.
Refresh token is essentialy a credential reference, that your client can exchange for access token, when there is no active user session.
For example if you want to periodicaly sync issues from Github with your inhouse system.
It is often misused like some kind of session. It is essential to diffirentiate those things. And scope name offline_access is there for a reason.
So in simple cases - you just rely on OP session and get new token with authorize/token endpoints combo. You should not be prompted to provide credentials as long as session is alive and consent is given for that particular app.
If you need to do some backgound stuff - ask for refresh token also.
As for question: no.
EDIT(More in-depth explanation):
if we are talking about web there are two main cases:
Client that can securely store secrets like usual web app with server page rendering and clients, that cant store secrets, like SPA apps. From that perspective there are two main flows (omitting hybrid to not over-complicate): Authorization Code Flow and Implicit Flow respectively.
Authorization Code Flow
On first request your app checks it own session(client session) and if there is none - redirects to external OP(OpenID Connect provider) authorize url. OP authenticates user according to requirements expressed in request, gathers consent and other stuff and returns authorization code. Then client asks token endpoint with it and receives access_token/id_token pair with optional refresh token if user granted offline access consent. This is important, because user can deny it for your app. After this client can request userInfo endpoint to get all user claims that were granted during consent. Those claims represent user identity and do not contain stuff like authentication method, acr etc. Those claims present in id_token alongside with expiration for example. After that client starts it own session and have option to set its lifetime equal to id_token lifetime or use it own to provide smooth UX for example. At this point you can discard access_token and id_token at all if you don't need access to other APIs(like all scopes in access_token are specific to OP and subject). If you need access to some API you can store access_token and use it for access. It becomes invalid - redirect to OP for new one. Expiration can be more lax here, because of more secure environment on server. So even 1hr is an option. No refresh tokens used at all.
Implicit Flow
In this case your lets say Angular app redirects to OP, gets its id_token and optional access_token from authorize endpoint directly and uses it to access some APIs. On every request expiration is checked an if needed, client sends request to OP in hidden iFrame, so there won't be any visible redirects as long as OP session is alive. There are some great libs for that like openid-client.js. No refresh is allowed here at all.
It is important to differentiate client session from OP session, token lifetime and session lifetime.
To address some specific needs there is Hybrid Flow. It can be used to get authorization code and id_token for your session in one request. No chit chat over network.
So when you think about refresh token just check your needs and map them to a spec :) And if you need it anyway - store it as secure as you can.
Refresh tokens are useful for applications that keep access tokens in a server session. For example if a web application doesn't call a protected service using JavaScript XHR, but calls its backend and the backend calls the service. In this scenario, it's easier to get a new access token whenever it's needed than asking a user for a new one.
In JavaScript applications running in browsers, refresh tokens cannot be used, because you need a client secret to get an access token from the /token endpoint and you cannot keep the secret safe in such applications.
The process for getting new access tokens you described can be improved - an application may ask for a new access token just before the current one expires, so the user doesn't get redirected to the OAuth2 server, but the application calls the /auth endpoint with prompt=none parameter in an iframe.
How I can enable multi resource support in iOS using ADAL.Searched in so many sites, but finding it difficult to understand the flow with multiple resources, with Refresh Token and Access Token.Can anyone explain this flow briefly please?
According to library, ADTokenCacheStoreItem will have accessToken will be nil, in case the item stores multi-resource refresh token.But whenever I will call acquireTokenWithResource:clientId:redirectUri: I am getting both access token and refresh token.How I can tell the library that mine is multi source request.Is there any settings I need to do?
/*! The access token received. Should be nil, in case the item stores multi-resource refresh token. /
#property NSString accessToken;
And also , do I need to call the acquireTokenWithResource:clientId:redirectUri every time before calling each API with or without different end points.Or is it my responsibility to cache/store the access token and expiry date for each resource?
Also how I can handle silent login in multi resource case?
With ADAL, you simply need to call some form of acquireToken* each time your application needs an access token, presumable to make an API call. ADAL should take care of token caching, refreshing, etc for you. You shouldn't ever have to manually use refresh tokens.
Refresh tokens from Azure AD are inherently "multi-resource". That is, you can ask for an access token to resource 1, receive that access token + refresh token pair, and then use the refresh token to get an access token to resource 2. This allows you to get tokens for different resources "silently", meaning the user only has to sign-in once.
I have two clients, one Public Client used by regular end-users logging in via our web page or native apps and one Confidential Client for our admin system. Both issues two JWT's, one Access Token and one Refresh Token.
The Public Client is not allowed to issue admin rights. The Access Token is short lived, and the Refresh Token has infinite life span.
The Confidential Client is allowed to issue admin scopes. The Access Token is short lived, and the Refresh Token lives 24 hrs.
Is it possible, using Spring Security and their oAuth2 implementation, to downgrade the admin user once the refresh token is expired? That is, once the user have been logged in for 24hrs, the user is not totally logged out, but on the next login he gets two new JWT's, one Access Token for regular user access and one matching Refresh Token for that access level. I guess I'm looking for some kind of hook in the Spring Security framework that allows me to handle token expiration in a customised way.
There's a sentence on your question that confuses me a bit, but I wanted to elaborate on other aspects so this did not fit in a comment.
... the user is not totally logged out, but on the next login he gets two new JWT's, one Access Token for regular user access and one matching Refresh Token for that access level.
What do you exactly mean with on the next login? My confusion here is that if the objective is not to logout the user, then there won't be a next login. I guess this could mean that almost to the end of the refresh token expiration you would want to do your downgrade request and use the still valid refresh token to get a new pair of tokens with less permissions.
According to the OAuth specification you can perform a refresh token request and ask the server for an access token that has less scopes than the one you currently have. However, it also dictates that if a new refresh token is returned, then that token needs to have the exact same scope as the refresh token included in the request.
Personally, for this scenario I would consider instead of downgrading tokens just ensure that in order to perform any administrator related operation the user must be an administrator and actually provided his credentials in the last 24 hours. You could accomplish this by tracking the date and time a given user actually performed a login (by providing their credentials) and then authorize administrator actions based on that value. This way you can increase the lifetime of refresh tokens for the confidential client and only force the administrators to login again if they want to perform a privileged tasks and their current tokens aren't fresh enough.
Finally, still on the subject of refresh tokens (with focus on the security considerations section)... when you say web app for the public client I'm assuming it's a browser-based Javascript application. If this is correct it's generally not recommended to use refresh tokens for these applications because refresh tokens are usually long-lived (in your case they seem to never expire) and the browser cannot ensure secure storage for them. This increases the likelihood of them leaking which would give an attacker access to the application for the lifetime of the token. You may have other constraints that make this security consideration not applicable, but I wanted to call your attention to it nonetheless.
For a B2B REST API servicing Enterprise clients who may have multiple applications using a Client ID/Secret:
If you send a request for an oAuth2 access token for a specific Client ID and Client Secret and receive an access token then later on send another request for a token with that same Client ID/Secret, should that invalidate the previous access token?
In other words, in this case, should a Client ID/Secret be able to request and use multiple valid access tokens? Are there different cases where this should be implemented or not?
OAuth2 is generally about a user delegating access to a client, so in the case where a client has many users (as it usually will), it will most definitely be using multiple access tokens since they will apply to different users.
Consider the situation where you grant access to your Google account to another online application (the client). Google issues an access token which might allow the client to read your contacts, for example, using Google's OAuth2 APIs (with your prior approval). Obviously it can only access your contacts with this token, not other people's. Google may issue many different access tokens to the same client, but each may correspond to a different user and/or resource.
The same authorization server may issue tokens for many different resources, so even in the case where there is no interaction with a user (as in the "client credentials" grant), a client may still need to manage multiple tokens.
Whether the authorization server invalidates a token when another is requested for the same user, audience, scope etc., would be implementation dependent. A client wouldn't usually need to do this and would normally use a refresh token to obtain a new token when its existing one was about to expire. I'd say it's generally more important that a user can invalidate existing tokens they have authorized, and that tokens can be invalidated for a particular client. Of course, this also requires that the resource server has some way of checking for token revocation before granting access.
Yes, a client can have several access tokens. It's meaningful, we're actually using.
Consider that tokens may have different scopes, so a client may have a token with scope "res1" for a resource and a another token with scope "res2" for a different resource.
Another use case may be to request a refresh token with several scopes, e.g. "read write" and use it to get a "read" scoped access token to initialize a management GUI, then get a new access token for each write transaction.
You can argue whether it's good design/implementation or not but it's definitely technically possible and not forbidden by the standard.
Assume we have an OAuth2 implementation that supports "read" and "write" scope.
I retrieve an access token "f482c829" with "read" scope. If I then change my mind and now want read+write permission and authorize again with "read" and "write" scope do you:
Update scopes for existing access token and return same token "f482c829"?
If using same token, require that the access token is reclaimed if using response_type=code before updating scopes? (I think yes)
Update scopes for existing access token and return a refreshed token "zf382nL"?
Create an entirely new token leaving "f482c829" and its scopes intact?
If you create a new token every time per scope, you end up having to store multiple access tokens per authorization and different permissions everywhere. I've been hesitant to implement it that way.
The OAuth2 spec (as of draft-12) unfortunately does not address any of this.
In facebook's case, resource server is basically same with authorization server.
So they do "use existing token" way.
And it enable to allow users to disable each scopes on facebook.com site.
About refresh token, you don't need to establish new refresh token. (Of course you can do it though.)
Existing refresh token will also be connected with all scopes.
In Google's case (maybe Yahoo! too), resource server is totally different from authorization server.
Many resource server (Docs, Buzz etc) accept access tokens established single authorization server.
In this case, "establish new token" way seems better.
In Twitter's case (maybe your case too), both seems OK.
Plus, in any way, when user revoked client access you need to revoke all tokens for the client.
User is not revoking "token" but "client".
Since developer should pre-register redirect_uri, using same client credentials both on website and on mobile all seems tricky.
So I recommend asking developers to use different client credentials in that case.
Say one client (mobile) of an application needs read-only access and another client (website) needs to write as well. This would require client to be able to decide the scope of token request and hence provider to store multiple tokens with different scopes.
However, it is up to you if you want to extend the scope of an existing token. This means you can keep one scope per application. This can also make easy to revoke access of an application by a user.