I'm using Ory Hydra as OAuth2 server. There's a config to set custom expiration time, but it's static and used for all tokens that I create.
https://www.ory.sh/docs/hydra/guides/token-expiration#access-token-expiration
I want to have the ability to set the token's expiration time when I create a token for the client (expiration time per token) or at least when I create the client (so I'll be able to use different expiration time for different clients). Is it possible?
Can you share a bit more on your use case?
AFAIK it is not possible to configure the lifetime of tokens per client at the moment. But in most cases I can think of this would not be necessary from a security standpoint, so I am would like to learn more why you are looking to configure the lifetimes individually.
If you have a refresh token the lifetime of an access token is negligible (in most cases) and best to keep reasonably short! In the scenario of web/native apps this definitely applies and you will have more complexity if you have different lifetimes as you will have when just following the refresh token flow.
Related
I need some lights about convenience of using an autheorizarion server in my project scope.
We're realising and deploying our services into customer environment.
Customer infrastructure already provides an authentication mechanism in order to authenticate users.
This mechanism intercepts all comunications and redirects user to a "login" form.
After that, user is redirected to our service and we've to handle and digest it and respond with an JWT token.
Here is where I'm feeling lost:
I'm thinking about:
using spring-oauth2 in order to request a JWT token to an authorization server, or
using spring-oauth2 in order to auto-generate an JWT token and validate it. I don't know if it's possible.
My question is, since user is already authenticated, have it sense to use an oauth2 authorization server, using client-credentials in order to authentication client against our resource services?
Short question would be, could I use spring-oauth2 librearies in order to generate a JWT without an authorization server?
You technically can do it, but I would discourage you from doing that. Access tokens in a system should be issued centrally, by a dedicated service. Otherwise, it will be hard to maintain the infrastructure. If your services will start to issue JWTs, then they will also have to provide the public keys for others to validate these JWTs. Keys management, access token contents management, and any rules of mapping user information into claims - will now become part of your service and it will unnecessarily complicate its implementation.
If the customer's authentication mechanism issues a JWT, why not use that one for request authorization? If that one is insufficient, I would recommend having an Authorization Server (or a dedicated service), that can perform Token Exchange and exchange the original JWT for a new one.
Currently building up a microservice for handling auth-related stuff using OIDC.
Now, we think about access control and how to be as future-proof as possible. This auth server is only used for first-party applications (3x SPA, 2x native mobile App). On mobile, we use the authorization_code grant. Each resource server validates the supplied token (access token as JWT) itself. But what happens when (in future), we add a service which needs its own scope to check (e.g. notifications:read)? As mobile app users are not used to logging in and out everytime (when we would update the requested scopes via an app update -> bad solution) is there any sweet solution to manage this scenario?
Per specification, it's possible to change the required scopes when refreshing a token but this is limited to require less scopes than originally requested and not more so that's not an option.
For example, Facebook is providing only four scopes for Instagram e.g. instagram_basic or instagram_content_publish. Zalando for example includes only a scope NORMAL_USER in their tokens whereas Wolt includes the users roles as a claim.
I think there is some confusion as this scenario is not covered directly by OAuth2 or OIDC. What are your thoughts about this?
There is one standard for doing OAuth 2.0 Incremental Authorization, but your challenge is to find a token provider that supports it or similar standards.
In a micro service architecture, the question is if you should use the access token from the authorization code flow everywhere, or if for service-to-service communication, you should use client credentials flow instead.
See also https://www.gmass.co/blog/oauth-incremental-authorization-is-useless/
It seems like you could use Token Exchange for that.
For example it could work like that - whenever your resource server gets a token without the notifications:read scope, issued before date x (so before you were issuing that scope) it performs an exchange with the authorization server and (if the server decides that it can perform the exchange) it gets a new access token that contains that scope. If the token was issued after date x you can safely assume that the token was not granted this scope.
Another solution would be to use claims for authorization decisions instead of scopes. The authorization server can issue e.g. a claim notifications_read: true, or something like that. Whenever you refresh tokens you can issue more claims in the new access token, the spec does not prevent that. Then your resource servers should check claims in the access token, they can ignore scopes. The resource server would just check whether the token contains the notifications_read claim with value true, or not. This solution gets a bit more complicated if you require your users to give consent to scopes, but as you said you're using this only for 1st-party, so I assume you're not using consent screens.
You can have a look at this free course - this topic of using claims in authorization is covered in part 4.
Looking at the Oauth2 specification, it says in section 6:
... the refresh token is bound to the client to which it was issued.
However, I can't find anything in the specification the explicitly states that the token should be bound to the requesting client also. I am assuming this to be the case, and the Introspection Extension seems to support that assumption, but I want to know if that is correct.
As an example, say I am using two applications that use Google as the Oauth2 Authorization Server. I'm assuming that Google will issue two different tokens, one to each application, and that the tokens can only be used by the client to which they were issued because they are bound to that client.
An access token can have various implementations. The one that is most widely adopted today is the "Bearer" token, in RFC 6750 https://www.rfc-editor.org/rfc/rfc6750. A Bearer token is not bound to the Client on purpose: it makes it easy to implement, lowers the barrier for adoption and caters for a wide range of use cases.
Assuming that a Bearer token cannot be easily stolen, it is acceptable to avoid binding it to a specific Client: the intended Client could indeed share the access token with another Client but it could just as well share the data that the access token permits access to if the token was bound.
In environments that demand higher security one could use a token that is bound to the Client as defined in RFC 7800 https://www.rfc-editor.org/rfc/rfc7800.
Yes, I think it is implicit in the specification that the access token should only be used by the application that the user authorized. Putting it differently - having something other than the authorized application use the token to access user data is pretty much the definition of a privacy failure, and is what authorization protocols are explicitly designed to prevent in the first place.
Now, in practice, I think that having one application use the access token from another would work fine in many OAuth 2.0 implementations. I don't thing the Token Introspection extension is widely used, and most access tokens are designed to be self-validating. Indeed, that's the reason why token stealing is a security risk. By contrast, the refresh token should only be useful when combined with the client secret, so it's "bound" to the client technically as well as philosophically.
Every article I've read vouching for the advantages of JWT state that one of these advantages is its ability for an auth system to be distributed across multiple servers. i.e . You aren't relying on a central repository of user auth details to do a lookup on every request.
However when it comes to implementation, I've read in many places that for added security you shouldn't just rely on the JWT signature verification itself, and that you should maintain a list of black or white list tokens generated by the server.
Doesn't this defeat the advantage I've listed above, as this list of tokens would need to be stored centrally where all servers can access it and it would require a lookup on each request?
How have people implemented this on their end?
You are making very good points in your question. Actually it would make sense to store an OAuth token at a central location in order to make it easier to implement signout/revoke functionality. If you just relied on the token signature you couldn't have possibly implemented such feature. Suppose that a user wanted to revoke an access token. In this case if you didn't have a central location/datastore for those tokens where you would have invalidated it and only relied on token signature, then the token would still have been valid.
So indeed, when you want to build more advanced systems that are dependent on OAuth tokens, a central store for those tokens is more than a must.
I'm working with a company that's implementing OAuth, and currently they're supplying an access_token with a lifetime of 180 seconds. This seems short to me, so I'm trying to figure out what a typical lifetime for an access_token is, from what other companies do on the web.
I've seen on the web that:
Twitter lets them live forever
Facebook expires them after ~60 days
So it seems to me that 180 seconds is way too short, as it will force developers to constantly have to use the refresh_token to request a new access_token.
Any suggestions?
EDIT: At first I was asking "What's a reasonable life time for an OAuth access_token?". I've changed the question to "What's a typical life time for an OAuth access_token?", as I think this is closer to what I actually meant.
Short answer:
What is reasonable all depends on the company policy and its OAuth implementation.
Long Answer:
The access token lifetime is really up to the supplier of the token i.e. the Authorization Server of your partner company and its policy.
I would agree that 3 minutes is very short but the company's security policy may demand that on revocation of certain permissions or account removal, access for clients who were granted access based on those permissions is disabled within no more than 3 minutes. The fact that this comes at the cost of quite significant network and processing overhead is something that is calculated in (hopefully).
The cost (as in: overhead) of that decision also depends on the usage of the token itself. It it is used infrequently but always in burst mode, the overhead may be relatively low. If it is used frequently but just for one API call each time, then the overhead is relatively large and thus the cost higher.
Most environments wouldn't require immediate removal of all delegated access on the spot and would find it affordable to deal with a delay of at least 1 hour.
On the other hand, Twitter and Facebook are implementing OAuth in such a way that they can afford long-lived access tokens: when the Resource Server receives an access token, the permissions associated with the account that issued the token are checked. Of course for performance reasons the Resource Server will cache those results (for the sake of the discussion, say for a duration of 3 minutes) but effectively it yields the same result, pushing the "refresh overhead" to the Resource Server instead of the Client. (Note that this somewhat defeats the purpose of using structured self-contained access tokens such as JWTs).
The approach of Twitter and Facebook works if you don't need/want to explicitly authenticate your clients again within reasonable bounds. Since Twitter and Facebook also don't authenticate their users very often, that approach make sense for them.
I guess you could say that each use case is different: it all depends on what you want and how you implement it. And your company and Facebook may not be comparable because they have different tokens, Resource Server implementations and restrictions on client (and user) authentication.