You and I have a different understanding of how OAuthV2 works.
The Password grant allows the OAuth token dispensary to authenticate the user with a password; a correctly behaving token dispensary will issue a token via password grant_type only if the user is authentic. Normally if you use Apigee Edge to dispense the token, you would configure the token dispensing flow to:
- authenticate the user via an external Identity Provider (IdP)
- using the response from the IdP, attach some custom metadata (like an email address, or even a set of roles belonging to the user) to the token as a custom attribute during generation.
You wrote:
I cannot associate the email (userID) with OAuth2 access token when I call “/ product”, …
I disagree. In fact, you CAN associate an email with a token. Everyone who is using Apigee Edge correctly, does this. This is normal, standard, best practice for tokens issued via password grant.
Suppose Apigee Edge has issued a token via password grant, and has associated an email address and role to the token, as described above. Now imagine a subsequent request that presents the token back to Apigee Edge. The API proxy calls OAuthV2/VerifyAccessToken , and that implicitly loads into the request context, the metadata associated to the token including the custom attributes (like email or role) that were attached to the token during generation.
At that point you could configure your API Proxy to take conditional action based on the email or role, etc.
…the client application can request my API with the same Token and different emails and will have an unauthorized access to protected data.
No. When using tokens generated via password grant, the client does not send in a token along with an email address, and an assertion that the token is usable for that email address. The client sends only the token. The Apigee Edge server validates the token, and loads the metadata persistently associated to that token. For a token issued by password grant, the email address is stored as metadata for the token, at the token store. The client cannot tell the Apigee Edge server that the token belongs to a different email address than the email address stored with the token by Apigee Edge.
Also, for tokens generated via password grant, the client is TRUSTED. This is because the client itself handles user credentials. A malicious client could store those creds and replay them at any time to obtain new tokens on behalf of the user, and then perform arbitrary actions. Therefore we assume that the client participating in a password grant is trusted. As a corollary of that Trust, we assume that the client uses tokens correctly - does not covertly store them and replay them later, without user consent.
By the way: If you do not trust the client to handle user credentials, for example if it is a third-party client, then you would use authorization_code grant_type.
In the end, the client obtains and handles the token; the client must be trusted to NOT re-use that token in a context that is not on behalf of the user.
