OAuth 2.0 Client Credentials Grant

[FMaCT]

Summary

To access The Things Stack (API) as an application (without any user involved), it would be good to be able to use the OAuth 2.0 Client Credentials Grant.

Current Situation

Currently this scenario can be achieved using an API key or the (deprecated) OAuth 2.0 Password Grant. The OAuth 2.0 client credentials grant however is considered more secure than API keys, due to:

• Delegated access and an additional layer of indirection through an authorization server, whereby secrets never get transmitted to the resource server and
• Validity time limits for access tokens

As already mentioned, the OAuth 2.0 Password Grant is deprecated.

Why do we need this? Who uses it, and when?

Applications which use the The Things Stack API would/should use the OAuth 2.0 Client Credentials Grant instead of using API keys.

Proposed Implementation

Just like the other supported OAuth 2.0 grants. Ideally the option should also be provided for integrations from The Things Stack to other systems (outbound connections).

Contributing

• [ ] I can help by doing more research.
• [ ] I can help by implementing the feature after the proposal above is approved.
• [ ] I can help by testing the feature before it's released.

Code of Conduct

• [X] I agree to follow TTN's Community Code of Conduct.

[adriansmares]

OAuth clients in the context of The Things Stack do not have the concept of access to individual resources. They gain delegated access to the resources of the logged in users, but they do not own or access resources on behalf of themselves. As such, enabling the client credentials flow would require quite significant changes to the underlying architecture of The Things Stack, without significant gain.

API keys can already have fixed duration (expiration date), and in the context of The Things Stack as a whole, the authorization server and the individual resource servers are within the same side of the security boundary. User and organization API keys can also be scoped to individual resource types if a stronger separation is needed, and applications and gateways API keys can guarantee that individual keys can access only specific resources.