LinkedIn
Twitter
1 ACCEPTED SOLUTION
Before I answer, Let's set some foundation.
For each API product, the API publisher can specify valid scopes.
To kick off a 3-legged (authorization code) OAuthv2 grant flow, the client app performs a GET on a URL that includes a query param, which specifies a set of one or more scopes. There's another query param that specifies the client id, which refers to a specific set of one or more API products.
Then some redirection happens:
- a 302 from the Edge proxy to the the login+consent app.
- Upon successful login/authentication, this happens:
- the login+consent app calls into an Edge proxy to run the OAuthV2/GenerateAuthorizationCode policy. The login app sends in the requested scopes.
- Edge validates the request, and if valid, generates a code
- login app receives the authorization code
- sends a 302 back to the client, containing the authz code. This 302 points to the Edge proxy. The scopes on the token are identical to those validated and checked during the GenerateAuthorizationCode step.
- the client app then GETs that URL, which generates an access token
If the scopes sent by the login app into Edge, to request generation of the authorization code, are not valid for the given set of one or more API products that are valid for the client_id, then... the OAuthV2/GenerateAuthorizationCode policy in Edge will send back an error. ("invalid scope" I think). And in this case no authorization code is generated.
ok, given all that.... at which point do you want to query the scopes?
And which actor is doing the querying?
I have built login apps that perform a call into a custom endpoint on the Edge oauth proxy, to inquire "which scopes are available on this client_id"? This way the login+consent app could show a set of checkboxes for all the scopes, and the user could optionally select or deselect those scopes. Then, when the user says "OK" the login+consent app could request a code with a specific set of scopes, which presumably is the intersection of (scopes requested by client app) and (scopes approved by user), which is a formal subset of (scopes available on the API product).
To make that happen you need to expose an endpoint on your oauth proxy that accepts a client_id, and then calls OAuthV2/GetOAuthV2Info with that id, to inquire the product or products, and then determine the scopes of those products. And then send that back to the login app.
