Skip to content
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

Link configuration "supported" options to behaviour #22

Open
tekul opened this issue Apr 24, 2015 · 1 comment
Open

Link configuration "supported" options to behaviour #22

tekul opened this issue Apr 24, 2015 · 1 comment
Labels

Comments

@tekul
Copy link
Owner

tekul commented Apr 24, 2015

These are currently ignored, other than as provided to the client via the discovery response. The client can still use unsupported options in requests and have them processed. For example

  • responseTypesSupported should be checked when processing an authorization request
  • algorithmsSupported should be checked in id token creation, user info responses, request object (when implemented) and client auth signing. It may be sufficient to check some of them when registering the client, since the client's specific algorithms are stored with its data.

Both these and clientAuthMethodsSupported should be checked when registering the client.

tekul added a commit that referenced this issue Oct 15, 2015
Checks registered algorithms and client auth method during registration
against those supported by the server configuration and returns an
invalid metadata error if the values are not supported.

See #22.
@tekul
Copy link
Owner Author

tekul commented Oct 16, 2015

See also:

http://tools.ietf.org/html/rfc7591#section-2.1

and

http://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata

for information on validating the requested grant types based on supported response types.

tekul added a commit that referenced this issue Oct 16, 2015
Now checks whether the OP is configured to support the requested
response type and returns an error if not.

See #22.
tekul added a commit that referenced this issue Dec 1, 2015
If the client registers with the implicit grant as but the OP does not
support any response types which imply the implicit grant, a metadata
error is returned.

See #22.
@tekul tekul added the bug label Nov 24, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant