Does this library support client credentials grant type?

[videni]

Does this library support OAuth 2.0 Client Credentials Grant Type please? I didn't find any doc about this ,

[videni]

I checked the soure code, it seems not supported yet.

[videni]

@HeroicKatora , the client credentials grant type might be the easiest one in oauth2, are you interested?

[HeroicKatora]

Without commenting on the complexity of the grant type, yes, I would be interested. It should be possible to re-use the existing primitives for this, i.e. a combination of issuer and registrar.

[videni]

Are you willing to implement it? otherwise, I will try to add it later.

[HeroicKatora]

I'm afraid I won't have the time to do so myself in the nearby future. However, I'd be willing to provide some mentoring and code review on a PR.

[danielalvsaaker]

I'm also interested in this, and wondering how this is best implemented. Should AccessTokenbe generic, swapping the inner state machine depending on the grant type?

[HeroicKatora]

The existing backend algorithms shouldn't become generic, I think this would vastly overcomplicate their analysis and testing. I would approach the problem this way:

1. Create a new state machine in code_grant::accesstoken for the ClientCredentials kind. Note that input and output of that machine isn't quite the same because we need to handle scopes that are otherwise in authorization and also the extension module would work differently.
2. Add some explicit new builder (or constructor) to the AccessTokenFlow that allows dispatching to that new state machine in its execute method, instead of access_token.

[foxfriends]

I took a brief look into what it would take to build the client credentials flow, and ran into one main roadblock that the Issuer::issue requires a Grant (and the Registrar a PreGrant) which includes stuff like redirect_uri and owner_id. No expert at OAuth, only started playing with it last week, but if I'm not misunderstanding, those seem to be irrelevant for the client credentials flow?

Additionally Registrar::negotiate requires the BoundClient, but it seems in the client credentials flow, we won't have that either, just a client_id which may affect the scopes you are allowed to ask for.

Any thoughts on how that might be handled? A new set of Issuer and Registrar-like traits for client credentials support that use different types than Grant/PreGrant, or just making the existing Issuer/Registrar less strict about what is passed in?

I am looking for this feature too, is there a chance it could be added soon? Or if there is a clear way forward I would consider attempting to implement this at some point as well.

[HeroicKatora]

I wouldn't consider any of these roadblocks. It seems perfectly fine to require a redirect_uri for all clients, even if these clients will only use the client credentials flow. Indeed, its main purpose is a constraint: 'Do not redirect the user agent to any address other than' when issuing tokens. If not redirecting at all, the constraint is merely unused. A client that never attempts to retrieve any tokens via the token flow then that client can also be registered under any invalid URL (e.g. under the standard invalid. top level domain).

BoundClient is a type to apply this constraint at a type level, and if none is specified then the field from the registration is used. Again, this can also use the invalid TLD just fine if no redirect happens as part of the flow.

The owner_id is the resource owner, if you can't find one then you shouldn't use OAuth. Not having one is a security risk, so you could say that problem is 'by design'. It may be that the client itself is the resource owner, in which case you may just copy that field.

[foxfriends]

Ah thank you for the explanation, this makes sense. I will try again with that in mind!

[ondrowan]

Since this grant type has been added in v0.5.3 I guess this issue can be closed.