1
votes

Our Mobile Client App uses https://identityserver:port/oauth2/token service from Identity Server by passing the ClientID and ClientSecret with grant_type as “client_credentials” to generate the access token. The generated access token is used to invoke the API from ESB.

As per the implementation the ClientID and ClientSecret will be stored in the device.

For an example, ClientX requested for an Oauth Token which will have a certain expiry time. Can this token make as a unique for ClientX?

Currently all the upcoming client calls will get the same access token as its already generated from the request of ClientX. If a client is requesting a token very late it will get the same token with almost expiry time.

Is there a way to make this token unique for the Client?

2

2 Answers

0
votes

In your case, if you use “client_credentials” as a grant type, resource owner is also the client.

Since this is a mobile application, once your mobile app gets the token it will be used until the expiry date and there will not be a necessity of changing it, because of mobile is belongs to a single user. Therefore the token would be same for same scope till it is expired.

Ex: BBC news mobile application.

If you need different access tokens, you need to use different scopes.

You will need different access token in case if different clients accessing the same API. In that case you may use “PASSWORD” grant type for a unique access token.

Ex: Purchasing a product using ebay.

So you should define your scope properly to identify the use of access token.

Find the following blog that will help you to guide to select your scope. [1]

[1] http://wso2.com/library/articles/2014/02/securing-your-web-service-with-oauth2-using-wso2-identity-server-1/

0
votes

I will assume that mobile application instance is bound per user.

If you want to get different access tokens for every user bound to a session don't use client_credential grant type.

For example you have client-x and client-y both using client_credentials grant. Identity Server (Authorization Server) will give an access token for client-x and client-y since this is about authorizing client-x and client-y to access resource and not about authorizing a user. This means whatever user you have in client-x or client-y requesting access_token, they can get one (assuming they are authenticated).Vice versa, a user, even if authenticated both client and identity server cannot get an access token if the request comes from client-z (client-z is not registered in identity server)

If your Oauth 2.0 client is browser-based you can use implicit grant, if it is a server you can use either authorization grant or resource owner password credential.