feat: Breaking changes to SmartAuthProvider#170
Conversation
jdjkelly
commented
Dec 14, 2021
- A new interface replacing the previous type
- Root keys are simpler
- Allows explicitly for the expression of Client Credentials flow clients
* A new interface replacing the previous type * Root keys are simpler * Allows explicitly for the expression of Client Credentials flow clients
acr13
left a comment
There was a problem hiding this comment.
Couple questions / comments but for the most part looks great
|
|
||
| interface ClientCredentialsConfig extends SmartAuthConfig { | ||
| grantFlow: "client_credentials" | ||
| }; |
There was a problem hiding this comment.
for the client_credientials grant flow, are we banking on tokenParams having a scope property?
There was a problem hiding this comment.
No - if it has it, we will use it. But it doesn't need it.
In most OAuth 2.0 libraries, including simple-oauth2, you get to specify the "default" scope you want to use for a given Authorization Code grant flow request. When you want to support different grant flows with the same config, things get a little trickier because scope is also used in the Credentials Grant flow.
How do they each work?
In the Authorization Code grant flow the scope value is used during the authorization URL creation step (the place we redirect the users to first). scope is commonly used as a global config value that is used for every single authorization URL, but there's no reason that you can't change it per request.
This might make sense for example when you have an app that flexibly lets the user select which scopes they want to give to the app. You could in advance ask the user what they want to give you, before redirecting them to the authorization URL.
The param scope also happens to be used by the Client Credentials grant flow but it's very rarely ever going to make sense to have the same default values. Making a Client Credentials grant flow with scopes that are the same as a user is sort of disjoint from the point of the CC grant flow: to give you application instead of user-level access to some resources. Worse, SMART App Launch as a spec says absolutely nothing about Client Credentials.
There was a problem hiding this comment.
So, if you set up a SmartAuthProvider with the Client Credentials grant flow, we're going to listen to anything you want to specify in tokenParams but no other defaults.