Hi - I'm glad you're checking out the Open ID Connect example.
It's possible you know this, but let's state it anyway just to make sure:
The Access Token is different than the ID Token.
The ID token is a JWT, and can be decoded and then digitally verified , with the right key. The JWT contains claims like "sub", "iss" and so on. This ID token is intended primarily for use by the client app. The IdP , which in this case is an API proxy bundle running in Apigee Edge, is issuing a signed token containing a set of assertions about the person or user. The client app can then rely on those assertions as being bonafide and valid.
The Access Token is different - it is intended to be retained by the client,but not interpreted or validated by the client. The client passes it to the API Gateway, which again in this case is Apigee Edge, when the client app makes requests on behalf of the user. The Access Token is an opaque string of characters. It cannot be decoded, except by the issuer (Apigee Edge). A client app presents it to the API provider (Apigee Edge) with a request and the provider can verify the token before allowing access to the APIs. The client app generally does not present the JWT (ID Token) to the API provider when requesting service.
ok, now that we have that bit out of the way. ...
I understand that you would like to allow the backend system, or even the API Proxy itself, to gain some knowledge of the user for which the access token was issued. You can do that with Apigee Edge.
We know that the client app is going to present the access token to Apigee Edge.
Every access token in Apigee Edge has associated to it, in the secure store, additional attributes. These attributes include: issued-at time, API Product name, expiry, and so on. Some of these are similaer to the claims you will find in an ID Token (JWT), but understand that these are distinct tokens, therefore they are distinct claims. To refer to the things associated to the opaque access token, I will sometimes use the term "metadata". As a person who controls the configuration of policies in Apigee Edge, you can tell Apigee Edge to attach custom attributes to the token, when it is issued. One example of a custom attribute you want to attach to a token might be "username".
The way to attach custom metadata to a token is using the Attributes element, like this:
<OAuthV2 name="OAuthV2-GenerateAccessToken-AuthCode">
<DisplayName>OAuthV2: Generate Access Token</DisplayName>
<ExternalAuthorization>false</ExternalAuthorization>
<Operation>GenerateAccessToken</Operation>
<SupportedGrantTypes>
<GrantType>authorization_code</GrantType>
</SupportedGrantTypes>
<!--
Optional: these attributes get associated to the token.
They will be made available to the api proxy via context variables,
when the token is subsequently validated.
-->
<Attributes>
<Attribute name='username' ref='sub' display='false'/>
</Attributes>
<GenerateResponse />
</OAuthV2>
The 'sub' in the above refers to a context variable - something that is available within the request variable inside the Apigee Edge proxy. Context variables are ephemeral; they last only for the duration of the API request, which may last 10 milliseconds. But with this policy configuration, you are telling Apigee Edge "create a new token, and store an attribute called 'username' with it, and give that attribute the value of whatever is currently contained in the context variable called 'sub'."
You can read more about custom attributes in the Apigee docs.
When you configure the GenerateAccessToken policy this way, the generated token looks exactly the same. The client cannot tell that you have attached this metadata (the username) to the token. Instead what happens is, Apigee Edge stores in its token datastore, the random string that is the token, and the metadata, which in this case will include the username string.
And , when the client presents that token BACK to Apigee Edge when requesting service, Apigee Edge will READ the token store, retrieve all the metadata, and will be able to see "hey, this token was issued on behalf of username xxxxx".
It's up to you, the policy configuration person, to take some action based on the value of that custom attribute.
LinkedIn
Twitter
