This repository has been archived by the owner on Feb 25, 2019. It is now read-only.
Enforce client grant_types and response_types #217
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The OpenID Connect specification makes it clear that this property is optional, and does not need to be specified in order to register a client. However, it provides a desired default value and behaviour. Marking this property as required in the schema and providing a default value effectively makes it optional, as the default value is used whenever a desired value is not explicitly specified. This falls in line with the defined behaviour in the specification.
The OpenID Connect specification makes it clear that this property is optional, and does not need to be specified in order to register a client. However, it provides a desired default value and behaviour. Marking this property as required in the schema and providing a default value effectively makes it optional, as the default value is used whenever a desired value is not explicitly specified. This falls in line with the defined behaviour in the specification.
Validates that clients have the appropriate grant_types defined for their desired response_types per the Client Metadata section in the OpenID Connect Registration 1.0 specification http://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata
Makes behaviour consistent with the rest of Anvil Connect, where the lack of a NODE_ENV environment variable value denotes that the server is in a development environment.
…rce-grant_types-response_types
|
Reviewed. |
christiansmith
added a commit
that referenced
this pull request
Sep 3, 2015
…pes-response_types Enforce client grant_types and response_types
adalinesimonian
deleted the
vsimonian-enforce-grant_types-response_types
branch
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #95 #96
Breaking changes
Existing client registrations that did not follow the OIDC specification will now behave according to specification. Clients must now be explicitly registered with the sets of
response_typeandgrant_typevalues that they will use.For example, a client that intends to use the implicit flow must have
token id_tokenorid_token tokendefined on itsresponse_typesclaim andimpliciton itsgrant_typesclaim in order to work.Existing clients without a defined
response_typesclaim will act as though their only supportedresponse_typevalues arecode. Clients using other response types must have their registration data updated usingnv update client [id] [json]or otherwise.Summary
response_typesandgrant_typescode id_tokenis equivalent toid_token codeNODE_ENVset no longer validates client metadata with production logic