Best practice to identify user by access token

[#1]

Thanks to @Dino 's lab. I created two proxies; access token dispenser proxy and verifier proxy. It worked well. Now I want to know how to identify user info from access token.

I need OAuth2 Password grant type for our first app. I want the following steps.

(1) The app sends a request to get access token with Consumer Key and Consumer Secret (base64 format) and user's ID and Password.

(2) Apigee verifies the Consumer Key&Secret and send request to Identity Provider with the user's ID and Password.

(3) The the user's ID and Password are valid, Apigee returns access token.

(4) The app can call backend API with the access token.

(5) The backend API returns the user's private data which is not open to the public.

The step (1) to (4) are working. I need the step (5)

I think I have to store the access token and user_id into somewhere (lile Apigee KVM) at after the step (3). Then, I think I can add the user_id on HTTP header at post-flow of the step (4)

Do you have any idea? I'd like to see any examples.

token-dispenser and token-verifier examples are saved here.

https://github.com/y-zono/apigee-examples/tree/master/apigee-examples/oauth2-password

[#2]

I found the similar question and the answer. It seems that "Attributes" can be useful.

Oauth 2.0 - Resource Owner (user) specific tokens

https://community.apigee.com/questions/20394/oauth-20-resource-owner-user-specific-tokens.html

I noticed now that @Dino 's example uses the "Attributes".

https://github.com/y-zono/apigee-examples/blob/master/apigee-examples/oauth2-password/oauth2-passwor...

The comment "these attributes get associated to the token" means I can get these attributes by the token? If so, how?

I guess "OAuth 2.0 Token Introspection (RFC 7662)" might be related to my question. My backend api should make a request to verify and retrieve data by the token..?

[#3]

I found the way from apigee examples. I added "SetValidTokenResponse" into my proxy config.

https://github.com/y-zono/apigee-examples/blob/master/apigee-examples/oauth2-password/oauth2-passwor...

Then I confirmed that I can retrieve user info from access token like the following.

$ curl -H "Authorization: Bearer xxxxxxxxx" https://xxx-eval-test.apigee.net/oauth2-verify
{"expires_in":"", "user":"dino@apigee.com"}

I guess that making the above api request (/oauth2-verify) from backend api might be a good way to verify access token and retrieve user data. Do you agree with that?

[#4]

I still have a question that where is the data (access token and the associated data) stored. Is it possible to see on the Apigee Edge?

[DChiesa · Accepted solution]

I guess that making the above api request (/oauth2-verify) from backend api might be a good way to verify access token and retrieve user data. Do you agree with that?

No, I don't agree with that. Calling Apigee Edge from a backend is an anti-pattern. Apigee Edge is intended to be used as a reverse proxy. This means clients call Apigee Edge in lieu of calling the backend. Clients present the token (or other credentials) in the request they send to Apigee Edge; Apigee Edge verifies the client credentials; after successful verification, Apigee Edge proxies the client's call to the backend.

Under this model, any call that the backend receives is assured to have been verified by Apigee Edge. This allows developers of backend systems to build systems without any awareness of the Apigee Edge gateway, and in fact without considering that a gateway exists at all. The developer of the backend service can thus focus on the job at hand, rather than injecting security calls into their implementation.

It is certainly possible for a backend to directly receive calls and then call to Apigee edge to request verification of credentials. But it's an anti-pattern to do so.

[#6]

@Dino Thank you. Your explanation was really helpful!

I added AssignMessage policy to add "X-Authenticated-Userid" header. This is better way than calling Apigee Edge from a backend, isn't it?

https://github.com/y-zono/apigee-examples/blob/master/apigee-examples/oauth2-password/oauth2-passwor...

$ curl -H "Authorization: Bearer xxx" https://xxx-eval-test.apigee.net/oauth2-verify
{
  "args": {},
  "headers": {
    "Accept": "*/*",
    "Connection": "close",
    "Host": "httpbin.org",
    "User-Agent": "curl/7.54.0",
    "X-Authenticated-Userid": "dino@apigee.com"
  },
  "origin": "163.44.52.112, 104.154.179.1",
  "url": "https://httpbin.org/get"
}

[#7]

>The developer of the backend service can thus focus on the job at hand, rather than injecting security calls into their implementation.

I have concern about adding the "X-Authenticated-Userid" header by someone instead of Apigee. I think Apigee provide their ip ranges for paid users. Is whitelist-ip secure enough? Are there any solutions in order to avoid unauthorized access?

https://community.apigee.com/questions/51018/ip-whitelist-2.html

>In general not with Trial, or Start, or SMB licenses.

>With a paid commercial license, yes.