This repository has been archived by the owner on Jun 12, 2021. It is now read-only.
New session management #109
Open
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 tests added reflect current bugs that were not covered until now and were missed.
There might not be any client information at this time. This is an effect of automatic client registration as defined in the OIDC federation specification.
…classes that are built on this.
A warning is logged, as there can't be PKCE functionality without authorization and token endpoints.
There was a bug when plain code challenge method is not supported based on the configuration and PKCE is not essential, where all flows authentication requests without PKCE would fail because plain is not supported and is the default method. It's fixed now, but maybe there is an underlying issue here, concerning this use case; the PKCE RFC states that plain is the default method and we follow it, however we provide the option to not support plain. As a result each authentication request which has a code_challenge and omits code_challenge_method will fail. Is that behaviour expected or we should default in a code challenge method we support. Or should we always support plain?
Fix pkce bugs
Add add_scope option JWT access tokens, enabling this will add a list with the allowed scopes that were requested in the returned JWT.
…endpoint into new_session_handling
The user can now set the usual grant types to have a default configuration and class, without the need to set the oidcendpoint class path. This can be done by setting a value of "default" or None (no value in yaml dict).
Removed "default" value for grant types and added True instead. So now None or True enables the grant_type with the default class, while False disables it and of course a dict with a custom class uses that instead.
Add the options add_c_hash and add_at_hash to retrieve the tokens from the session_info and add their hashes to the id token
State can't be assumed to be unique ince the client chooses it so we can't use it as an identifier for getting the sid
Good feature, fully approved by reviewers
Feature configurable grant types
Remove call to map_kv2sid > There will probably be conflicts but that can be dealt with then. Ok, there Will be a new begin from this!
The access_token handler was used to mint auth codes
New session handling
Fix bug, default token_handler to None
We already have the grant in most cases so we can fetch the token from inside it instead of querying the DB again.
WIP: Make more fixes to the new_session_handling before it gets merged
New session handling
nsklikas
approved these changes
Apr 9, 2021
peppelinux
approved these changes
Apr 19, 2021
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.
The old session management system is rewritten.
The New Session Management subsystem are designed to support a couple of
different services that we have in, or are in the process of adding to, the
system as it is:
Single Logout
Described in a set of specifications:
- Session Management
- Back-Channel Logout
- RP-Initiated Logout
- Front-Channel Logout
Authorization management
Information about which tokens can be issued and what they are
supposed to be used for and by whom, must be managed somewhere.
Token exchange
As described in RFC 8693 - OAuth 2.0 Token Exchange
And some new functionality that we might want to support:
OAuth 2.0 Rich Authorization Requests
Allows clients to specify their fine-grained authorization
requirements using the expressiveness of JSON data structures.
FAPI Grant management
Wants to extend OAuth to include explicit representation of grants in
the OAuth protocol.