In this post there is a discussion of multiple policies in B2C to secure different endpoints, thereby forcing someone to login again for more sensitive resources.
This sounds great, and was echoed in this SO post where examples of Facebook or Google were given.
I've tried implementing this, setting two acceptable policies on one controller and a single policy on another.
And if you choose the page with the less secure policy and login, and then you choose the other page with the more secure policy, you're asked to login again. So far, so good.
But now the cookie contains the short lived expiration from the secure policy, so you'll be asked to login again after that cookies expires, even though your cookie from the original less secure login is still valid. And your stuck logging in repeatedly after the short interval of the more secure cookie.
How do I tell it to switch back to use the still valid old cookie (if it even still exists)?
I've been thinking about this and I'm not sure if a better way to handle it is to check the issued at claim in the authorization policy to see if it was recent enough and if not, return unauthorized so they'll be forced to login again. They'll get another long lived token at that point, with a new issued at claim and they're good to go anywhere on the site.
Any ideas?
TIA
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.
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.
The specification of OAuth2 states that an authorization server must not issue a refresh token when using implicit grant. In our use case we protect a RESTful API with OAuth2 and use a Single Page Javascript application as a client for this API. As it would be very difficult to redirect to the authorization server after an access token has expired, we are searching for a better way to get a new valid token. I could think about two different approaches and wonder which one could be better:
Use a hidden iframe to Rerequest a valid access token. For this it is necessary to include a parameter like “prompt=none” which tells the OAuth provider neither to challenge authentication, nor to display an authorization page. If the user is authenticated and has authorized the application the server will send back an access token in the urls # parameters. If one of the previous conditions is not fulfilled, it will redirect with an error like #error=authentication%20lost. With this behaviour we can use short lived access tokens also with an implicit flow.
We could use an additional scope (e.g. offline) which tells the server to hand out a refresh token. Even if the original spec says that implicit flow does not issue refresh tokens (which is correct if the client only uses OAuth it for a first authorization) you are free to define your own scopes for your particular application. You should consider to only allow this scope from well-known clients.
Both approaches are very similar to those of OpenID Connect. Unfortunately there are not many implementations of OpenID Connect at the moment. So first step would be to extend the OAuth2 server until OIC will be more popular.
So which approach should be preferred?
EDIT: The token endpoint needs client authentication, which is only possible for confidential clients like server-side applications. With the second approach it would only be possible to let the RESTful API in our case the resource provider to refresh the token and send it back to the client. I think this would be a security risk. So probably we have only one valid approach.
I'm trying to achieve the exact same thing at the moment.
I've actually implemented hidden iframe approach and then realized you have to be very careful with iframes. Any malicious website can contain your iframe and get access token easily if you don't specify X-Frame-Options.
Best approach for refreshing token should be password grant as specified by the spec. (I wanted my users to login with their facebook account & implicit flow was easier to develop this. I have not quite figured out how to do this with password grant.)
2nd approach also came accross my mind and seems much safer than the 1st to me, since you can usually trust the https & browser storage to keep your tokens secret.
Edit
I realized, even with X-Frame-Options most browsers can't prevent redirects, because this header is attached to the response body and redirected URL will be exposed, therefore access tokens exposed.
Update
Looks like hash fragment is protected by the browser when accessed from the parent page within different domain. So I assume #access_token is safe. My bad. Just as a reminder callback page has to store the access token in its own right, instead of (my original intention) delegating it to the parent page like window.parent.storeAccessToken(hash); which obviously is a dumb thing to do.
From the OAuth0 website:
If you need to authenticate your users without a login page (for example, when the user is already logged in via SSO scenario) or get a new access_token (thus simulate refreshing an expired token), you can use Silent Authentication.
As for the Silent Authentication:
However, redirecting users away from your application is usually considered disruptive and should be avoided, from a UX perspective. Silent authentication lets you perform an authentication flow where Auth0 will only reply with redirects, and never with a login page.
This will allow you to log back the user using an SSO token, without having to prompt him for credentials again.
If I just store the provider and uid in a cookie is it secure enough? Or should I encrypt one or both of them? Should I augment provider and uid with a secure token?
Are there any other considerations that I should take into account?
You can use a signed cookie. These are cryptographically signed making it impossible to alter their data without invalidating them. This kind of cookie is typically used to store Rails session id/content.
Keep in mind that these cookies can still be decoded (it's just base64), but it shouldn't be a problem as provider and uid don't need to be kept secret.
If you don't want the cookie's content to be readable, you can use an encrypted cookie.
You can read more about the different types of cookies proposed by Rails here in the ActionDispatch::Cookies documentation
You say you can sign a user into your website when she visits if you've stored the provider and uid values you get from omniauth in a cookie. The problem with this is that it's not reliable as a means of authentication. Do you want to actually authenticate the user of your website? Then you need much more than just data that will allow you retrieve a unique user id from your database, as you recognize. You need some sort of guarantee that the user id you're associating with the session represents the user you think it does.
"Remember me" essentially relies on the assumption that the user-agent (e.g., the browser) is used only by the user who you originally authenticated. Can you or your user be sure of that? (This is why websites require you to opt-in to "remember me" - when you check that box you're promising that nobody who doesn't have authorized access to your user account has access to your user-agent.) It's not hard to see that this is pretty much essentially insecure. You can sign or encrypt your cookies, but unless you know that the user-agent is only accessible by the user you authenticated, you don't know that the user who visits your website the next time is authorized to access the original user's account.
If you're using omniauth, then you're essentially relying on some 3rd party to authenticate your users for you, either as a Relying Party as defined in by the OpenID Connect specification, or using some kind of non-standard authentication scheme on top of OAuth 1 or 2. What you're essentially asking is "Can I securely authenticate a user via a 3rd party just once and then safely assume that any time the same user-agent visits my site, it's the same user?"
The answer is NO.
But admittedly, there's a trade-off here between security and usability, and some people might think the risks (if the user's account isn't that sensitive) are outweighed by the usability benefits. However, if you're relying on a 3rd-party provider to authenticate your users, then the usability difference is almost literally zero. If the user has already authorized your application on google, facebook, or whatever other provider, and if they have a current session with that provider, then when they click the "log in with [provider]" link on your site, they can be logged in with no additional interaction from the user. No passwords or usernames to remember and enter, nothing. So the worst that can happen is they have to log in to google, facebook, or whatever, if they aren't already.
What's more, if you do this, you get more assurance that the user is who they say they are. Each time your user "signs in" with an OpenID provider, you get an id token that says who they are, that they were authenticated by by the provider, when that authentication event took place, etc. So you're not just assuming they're the user with a particular provider uid, you're trusting the provider's assertion that they are. Of course, even this is not perfectly secure, because it's possible the user's provider account is compromised, or in theory the provider could be untrustworthy. But it's still an improvement over "remember me."
TL;DR "Remember me" is inherently not secure, and offers no meaningful usability improvement over requiring sign in via an OpenID provider on each visit. Don't do it.
I am trying to figure out how an access token in OAuth 2.0 should be used. To be more precise, I am trying to use the Google Plus API from a web application.
I am now able to get a code and from it an access token. The problem is that this token is only about 3600 seconds valid.
Is there a way to get another token without making the user go again through this process: https://developers.google.com/accounts/images/consent1.png because it seems a bit irritating. I know of the offline access and its refresh token, but it doesn't feel right to have permanent access to a user's account.
Do you have any ideas on how should I proceed?
I'm definitely not an authority, but I believe the answer is 'no'. The offline token allows you access without subsequent user approval, but only to the scopes to which the user already agreed when authenticating for the first time. Also, the user has the option of revoking your application's access at any time, which when combined with their previous consent means they both a.) know what they're allowing; and b.) can stop it at any time. Ostensibly, if a user uses your app enough that they constantly have to get a new token, they already trust it to act on their behalf within the scope you set, and the offline token is a way for you to take your relationship to the next level :)
I realize this is probably more philosophical than you were looking for, so apologies if it isn't pertinent to your situation.