OAuth 2 How to link Tokens to users

[epaxx1]

Excuse the question very new to Apigee and OAuth:

We need a way to keep an access and refresh token linked to a user's login. So that if another user logs in it will not reset the current access token.

Thank you for your replies. 

Let me go deeper with a better explanation. 

Billy logs into our site and belongs to company 1. Billy will then click a button to start a process which will get a token from Apigee.

At the same time Mary will log into our site and also belongs to company 1. Mary will then click a button to start a process to get a token from Apigee. 

How to make sure Billy's token is not deprecated?

[ankitajain]

Hi 

Token is generated for a particular user. For new user there will be a new token.

If this answer is not suffice then kindly elaborate your question. 

Ankita 

[Denis_KALITVI]

I think you asking about user session > e.g. if user logged in in BROWSER X, have OAUTH2 token attached, and then user logged in again to other browsers\mobile app, previous token will be deprecated? 

[epaxx1]

Thank you for your replies. 

Let me go deeper with a better explanation. 

Billy logs into our site and belongs to company 1. Billy will then click a button to start a process which will get a token from Apigee.

At the same time Mary will log into our site and also belongs to company 1. Mary will then click a button to start a process to get a token from Apigee. 

How to make sure Billy's token is not deprecated?

[dchiesa1]

We don't use the word "deprecated" to refer to something that happens to a token. Normally, word applies to a programming interface, or a feature. A producer of such an interface will say the feature is deprecated, to indicate, it will soon become unsupported, or it will become unavailable. This is a way to communicate to users that they should migrate away from the interface or the feature.

A token doesn't become "deprecated" ever. Tokens can be issued and valid, expired, and revoked. I don't think we have a flowchart that describes possible token states, and "life cycle". Let me try to explain verbally. All of the following is with respect to ACCESS tokens. Not ID tokens, or other kinds of tokens.

1. Token issuers (like Apigee) can issue new tokens. Sometimes people use the verb "mint" to refer to this token generation process. "Minting a token" means creating a new token.

   All systems that I know of that employ oauth allow multiple tokens to be generated on behalf of a single client, or a single company. Or both. Many systems allow multiple tokens to be generated on behalf of a single user. Just because Billy has a token doesn't mean that Mary or Murali or Muthi cannot get valid tokens also. Some Apigee systems have tens of millions of active tokens concurrently, for different users, all for a handful of "clients", all issued by the same "company."

2. Tokens in general can be issued with a lifetime, or an expiry. Maybe 15 minutes. When the expiry elapses, we say the token is expired.

3. Token issuers can offer to "refresh" tokens. Normally this really means "replacing the token with a different one, with a new lifetime." Refreshing a token can avoid the need for a user to re-authenticate. It can happen without user awareness or interruption.

4. Tokens in most OAuth2 cases are "Bearer" tokens. That means the presenter of the token is assumed to be the owner and, when a service (or API) receives a request accompanied by a token, the service can simply examine the token to determine whether to allow the request. If an app requests and receives a token, then transmits the token to some other app, and that other app presents the token in a request-for-service, the receiving service will normally use the token and only the token to decide whether to render the service.

   There are cases in which the service chooses to "bind" the token to something else, like ... the client's IP address, or the fingerprint of the client's TLS certificate. For example, the service can enforce that a token is good only if presented by a client operating from the same IP address that requested the token.This is a way to restrict token "leakage". The app presents the token, and that something else, and the service uses both of those things to make the authorization decision. As an analogy, consider a motor vehicle operator's license, with a  photograph of the authorized party. A traffic enforcement officer will not allow me to  present your operators license as proof that I am authorized to drive; the photo of your face "binds" that license to you.

5. When an app presents a token within the context of a request, the service layer (the API?) can "validate the token", which means, check that it is valid, not expired, and good for the particular service being requested. Imagine a metro system. It can issue tokens that allow a person to ride all day. Maybe there is a restrictive token that allows riding all day, but only on the green line. Tokens can be like that - they have a lifetime and they can be scoped for a restricted set of services.

6. A token issuer can "revoke" a particular token, usually based on an administrative request. Someone in authority believes a token has leaked and wants to prevent its use.  When a token is revoked, the token validator treats the token as no longer valid, irrespective of the token lifetime. More sophisticated token issuers can also "revoke" a particular client or developer or company, so that all tokens issued on behalf of those things will be treated as invalid at runtime. A token issuer might also allow administrators  to "unrevoke" revoked tokens. A previously revoked token would be treated as valid again, though still subject to the token lifetime. This makes less sense for specific tokens, more sense for a revoked client, or developer. 

Does this help?