I made a Security Token Service that connects to my identity store and returns an OAuth2 token with claims if valid. I'm using the Thinktecture.IdentityServer for this. Now I can pass the token to my API, but how do I use this token in my web services to make sure that it returns data that is filtered on the basis of the appropriate claims in the token?
I think some samples might exist here: https://github.com/thinktecture/Thinktecture.IdentityModel.45/tree/master/Samples/Web%20API but I'm not certain I understand what is happening here. Can someone please write a GET that parses identity claims from the jwt token and returns a set of the claims?
I think the answer can be found here, but these integration tests were much more helpful.
Related
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.
I am new to implicit flow using OIDC and I am looking for sample code. I could not find anything on internet. Can someone provide links to sample code anywhere.
Any help is really appreciated.
Switching from code flow to implicit flow usually just means changing response_type parameter in your authorization request to token instead of code (or id_token token if you also want the ID token). Then you read the token directly from the response from the Authorization Server (no need to exchange code for token). This should relatively simple to achieve with any OIDC client library, or even just a HTTP client.
Take any OIDC client and change the response_type parameter used by it. If you run any concrete problems I'll be glad to help.
I am novice to how oauth2 with JWT works But must to learn it in short time :) After reading bit I draw a conclusion abstract of its work as this.
now I have two question in my mind.
(1) Is my way of understanding of how OAth2 work is fine ?
(2) As far as I know after step 6 (diagram) no further request to authorization server. Then,anyone(intruder) know the token witch given by auth server can communicate to the web API and obtain unauthorized access.how does is not possible.
(I know that token not alter by intruder since then web api new that but without altering it still intruder can communicate to web api)
I know I have miss something please kindly show me where I have missed ?
You have to take security measures to protect your token from being stolen. This is no different than preventing session-id from being stolen in session based authentication.
Anyone with access to a valid token is by definition an authenticated user, no matter how the token was retrieved.
Whether your web API communicates with the authentication system directly is not relevant.
I need to realize SSO system using Oauth2.
I understand steps in oauth2, but I don't know what's the Specific algorithm in generating an authorize code or an access_token,maybe Hash or something.And I can't find it on the internet
OAuth 2 specs:
Access tokens can have different formats, structures, and methods of
utilization (e.g., cryptographic properties) based on the resource
server security requirements.
The format of the tokens (and authorization codes) are not defined by the specs, so there is no specific algorithm.
The specs do require:
The authorization server MUST ensure that access tokens cannot be
generated, modified, or guessed to produce valid access tokens by
unauthorized parties.
So, for instance a random UUID makes a fine token. You could also consider JWT tokens.
OAuth2 spec doesn't specify any algorithm or way to generate token value. You can use whatever algorithm, even serial number starts from 1, to generate those token values. You can use more complicated random number generation, encryption, crypto algorithm. Most of them are pretty quick to generate key value, but you need to check how fast current authentication server can generate a key and if it meets your service's requirement.
For example, for token generation in Spring Security, DefaultTokenServices generates access token and refresh token using random UUID.
Unless you want to implement your own Oauth generator, you can use existing providers like WSO2 API Manager for supporting your system. It is well documented and has many REST APIs for this.
access_token contains the claims. So do authentication of user/client and other validations as mentioned in oauth2 spec. Then if you consider JWT for access_token format then you can use jose4j api for access_token creation which supports JWE and JWS as well.
OAuth2 does not define a specific method to generate or protect tokens (authorization code, access/refresh token).
You can implement any strong symmetric cryptographic algorithm, so that you can protect or encrypt the token you are sending.
If you don't want to check token against database you should have this strong encryption.
If it is fine to check token against database you can use a key-value pair, so that you provide key to user and value is stored only in database.
I am creating an OAuth server which issues tokens to users. However, I don't want to store tokens in the database, and I want the processing to be fast.
What I'm thinking is to include various information in the token, so that when I decrypt it, the information is already enough to check for permissions and scopes.
I'm a little worried about the token's length growing as I add more scopes.
Is this a good idea? If not, what can you recommend?
What you are talking here is about InMemoryTokenStore which is the default implementation. Also Oauth2 already maintains the information required to check permissions and scopes in token in form of different access roles provided by authorization server to various clients. I think you don't need to explicitly store anything in token.