-
Notifications
You must be signed in to change notification settings - Fork 14
feat: add client credentials as a MUST #245
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 8 commits
2d67a84
f2fb705
6a5e05b
45ac134
fd21bf6
840ccef
3b8d430
0458856
69ea20f
50e297d
176406f
9ea7a00
cb232b3
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -438,6 +438,42 @@ Discovery 1.0 [[!OIDC-DISCOVERY]] resource by including `webid` in its `scopes_s | |
| </pre> | ||
| </div> | ||
|
|
||
| # Client Credentials Grant # {#client-credentials} | ||
|
|
||
| NOTE: This sections borrows concepts from OAuth 2.0 [[!RFC6749]], while the rest of Solid-OIDC builds on top of OpenID | ||
| Connect Core 1.0 [[!OIDC-CORE]]. The section is likely to be extracted into a separate specification in the future. | ||
|
|
||
| Authorization Servers MUST support the OAuth 2.0 Client Credentials Grant [[!RFC6749]] (Section 4.4) to enable | ||
| non-interactive authentication for scripts, automated agents, and server-to-server communication. | ||
|
|
||
| NOTE: Scripts and bots can also use Solid-OIDC without Client Credentials via the [refresh token | ||
| flow](https://www.rfc-editor.org/rfc/rfc6749#section-1.5), when supported by the server. | ||
|
|
||
| When using the Client Credentials Grant, the Client authenticates with the OP using a `client_id` and `client_secret` | ||
| pair previously obtained through client registration (either static or dynamic). The Client sends a token request to | ||
| the OP's token endpoint with `grant_type=client_credentials` and the `webid` scope. | ||
|
|
||
| ## Token Instantiation ## {#client-credentials-token-instantiation} | ||
|
|
||
| During Token Instantiation [[#tokens]], if the [Client Credentials | ||
| Grant](https://www.rfc-editor.org/rfc/rfc6749#section-4.4) is used, the OP MUST validate the `client_id` and | ||
| `client_secret`. If valid, the OP MUST return a DPoP-bound OIDC ID Token. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As already described, this section should emphasize the requirement for authentication, but not the particular mechanism for authentication. For example, this would be a more suitable line: During Token Instantiation, if the Client Credentials Grant is used, the OP MUST validate the client's authentication credentials. (Note, though, that this requirement is already present via RFC 6749 and restating it is, strictly speaking, not necessary)
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 50e297d makes the authentication requirement generic. |
||
|
|
||
| ## Solid-OIDC Conformance Discovery ## {#client-credentials-discovery} | ||
|
|
||
| For non-interactive use cases such as scripts, automated agents, and server-to-server communication, this specification | ||
| also requires that an OpenID Provider that conforms to the Solid-OIDC specification MUST advertise its support for the | ||
| [Client Credentials Grant](https://www.rfc-editor.org/rfc/rfc6749#section-4.4) in the OpenID Connect Discovery 1.0 | ||
| [OIDC.Discovery] resource by including `client_credentials` in its `grant_types_supported` metadata property. | ||
|
|
||
| <div class="example"> | ||
| <pre highlight="json"> | ||
| { | ||
| "grant_types_supported": ["authorization_code", "refresh_token", "client_credentials"] | ||
| } | ||
| </pre> | ||
| </div> | ||
|
|
||
| # Security Considerations # {#security} | ||
|
|
||
| *This section is non-normative* | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am ok with adding a requirement for the
client_credentialsgrant type, and it is important to note the this grant flow requires authentication. However, client_id/client_secret is only one type of authentication that could be used in this flow, and it is (arguably) not the most secure. I would be much happier if the requirements here are limited to:client_credentialgrant type MUST be included in thegrant_types_supportedarray of the.well-known/openid-configurationresourceRFC6749 section 4.4.2 and section 3.2.1 already include requirements for authentication, so there is no need to normatively reiterate that here. It is fine to use client_id/client_secret pairs as non-normative examples, but I would not require that as the lone authentication mechanism. RFC7523 presents another way to handle authentication using JWTs, and other mechanisms will emerge over time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
69ea20f makes example non-normative and notes RFC7523.