feat(oidc): add additional config options, accurate token times, and refactoring (#1991)
* This gives admins more control over their OIDC installation exposing options that had defaults before. Things like lifespans for authorize codes, access tokens, id tokens, refresh tokens, a option to enable the debug client messages, minimum parameter entropy. It also allows admins to configure the response modes.
* Additionally this records specific values about a users session indicating when they performed a specific authz factor so this is represented in the token accurately.
* Lastly we also implemented a OIDC key manager which calculates the kid for jwk's using the SHA1 digest instead of being static, or more specifically the first 7 chars. As per https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-web-key#section-8.1.1 the kid should not exceed 8 chars. While it's allowed to exceed 8 chars, it must only be done so with a compelling reason, which we do not have.
2021-07-03 23:44:30 +00:00
|
|
|
package oidc
|
|
|
|
|
|
|
|
import (
|
|
|
|
"crypto/rsa"
|
|
|
|
|
|
|
|
"github.com/ory/fosite"
|
|
|
|
"github.com/ory/fosite/handler/openid"
|
|
|
|
"github.com/ory/fosite/storage"
|
2021-07-10 04:56:33 +00:00
|
|
|
"github.com/ory/herodot"
|
feat(oidc): add additional config options, accurate token times, and refactoring (#1991)
* This gives admins more control over their OIDC installation exposing options that had defaults before. Things like lifespans for authorize codes, access tokens, id tokens, refresh tokens, a option to enable the debug client messages, minimum parameter entropy. It also allows admins to configure the response modes.
* Additionally this records specific values about a users session indicating when they performed a specific authz factor so this is represented in the token accurately.
* Lastly we also implemented a OIDC key manager which calculates the kid for jwk's using the SHA1 digest instead of being static, or more specifically the first 7 chars. As per https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-web-key#section-8.1.1 the kid should not exceed 8 chars. While it's allowed to exceed 8 chars, it must only be done so with a compelling reason, which we do not have.
2021-07-03 23:44:30 +00:00
|
|
|
"gopkg.in/square/go-jose.v2"
|
|
|
|
|
|
|
|
"github.com/authelia/authelia/internal/authorization"
|
|
|
|
)
|
|
|
|
|
|
|
|
// OpenIDConnectProvider for OpenID Connect.
|
|
|
|
type OpenIDConnectProvider struct {
|
|
|
|
Fosite fosite.OAuth2Provider
|
|
|
|
Store *OpenIDConnectStore
|
|
|
|
KeyManager *KeyManager
|
2021-07-10 04:56:33 +00:00
|
|
|
|
|
|
|
herodot *herodot.JSONWriter
|
feat(oidc): add additional config options, accurate token times, and refactoring (#1991)
* This gives admins more control over their OIDC installation exposing options that had defaults before. Things like lifespans for authorize codes, access tokens, id tokens, refresh tokens, a option to enable the debug client messages, minimum parameter entropy. It also allows admins to configure the response modes.
* Additionally this records specific values about a users session indicating when they performed a specific authz factor so this is represented in the token accurately.
* Lastly we also implemented a OIDC key manager which calculates the kid for jwk's using the SHA1 digest instead of being static, or more specifically the first 7 chars. As per https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-web-key#section-8.1.1 the kid should not exceed 8 chars. While it's allowed to exceed 8 chars, it must only be done so with a compelling reason, which we do not have.
2021-07-03 23:44:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// OpenIDConnectStore is Authelia's internal representation of the fosite.Storage interface.
|
|
|
|
//
|
|
|
|
// Currently it is mostly just implementing a decorator pattern other then GetInternalClient.
|
|
|
|
// The long term plan is to have these methods interact with the Authelia storage and
|
|
|
|
// session providers where applicable.
|
|
|
|
type OpenIDConnectStore struct {
|
|
|
|
clients map[string]*InternalClient
|
|
|
|
memory *storage.MemoryStore
|
|
|
|
}
|
|
|
|
|
|
|
|
// InternalClient represents the client internally.
|
|
|
|
type InternalClient struct {
|
2021-07-10 04:56:33 +00:00
|
|
|
ID string `json:"id"`
|
|
|
|
Description string `json:"-"`
|
|
|
|
Secret []byte `json:"client_secret,omitempty"`
|
|
|
|
RedirectURIs []string `json:"redirect_uris"`
|
|
|
|
GrantTypes []string `json:"grant_types"`
|
|
|
|
ResponseTypes []string `json:"response_types"`
|
|
|
|
Scopes []string `json:"scopes"`
|
|
|
|
Audience []string `json:"audience"`
|
|
|
|
Public bool `json:"public"`
|
|
|
|
|
feat(oidc): add additional config options, accurate token times, and refactoring (#1991)
* This gives admins more control over their OIDC installation exposing options that had defaults before. Things like lifespans for authorize codes, access tokens, id tokens, refresh tokens, a option to enable the debug client messages, minimum parameter entropy. It also allows admins to configure the response modes.
* Additionally this records specific values about a users session indicating when they performed a specific authz factor so this is represented in the token accurately.
* Lastly we also implemented a OIDC key manager which calculates the kid for jwk's using the SHA1 digest instead of being static, or more specifically the first 7 chars. As per https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-web-key#section-8.1.1 the kid should not exceed 8 chars. While it's allowed to exceed 8 chars, it must only be done so with a compelling reason, which we do not have.
2021-07-03 23:44:30 +00:00
|
|
|
ResponseModes []fosite.ResponseModeType `json:"response_modes"`
|
2021-07-10 04:56:33 +00:00
|
|
|
|
|
|
|
UserinfoSigningAlgorithm string `json:"userinfo_signed_response_alg,omitempty"`
|
|
|
|
|
|
|
|
Policy authorization.Level `json:"-"`
|
feat(oidc): add additional config options, accurate token times, and refactoring (#1991)
* This gives admins more control over their OIDC installation exposing options that had defaults before. Things like lifespans for authorize codes, access tokens, id tokens, refresh tokens, a option to enable the debug client messages, minimum parameter entropy. It also allows admins to configure the response modes.
* Additionally this records specific values about a users session indicating when they performed a specific authz factor so this is represented in the token accurately.
* Lastly we also implemented a OIDC key manager which calculates the kid for jwk's using the SHA1 digest instead of being static, or more specifically the first 7 chars. As per https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-web-key#section-8.1.1 the kid should not exceed 8 chars. While it's allowed to exceed 8 chars, it must only be done so with a compelling reason, which we do not have.
2021-07-03 23:44:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// KeyManager keeps track of all of the active/inactive rsa keys and provides them to services requiring them.
|
|
|
|
// It additionally allows us to add keys for the purpose of key rotation in the future.
|
|
|
|
type KeyManager struct {
|
|
|
|
activeKeyID string
|
|
|
|
keys map[string]*rsa.PrivateKey
|
|
|
|
keySet *jose.JSONWebKeySet
|
|
|
|
strategy *RS256JWTStrategy
|
|
|
|
}
|
|
|
|
|
|
|
|
// AutheliaHasher implements the fosite.Hasher interface without an actual hashing algo.
|
|
|
|
type AutheliaHasher struct{}
|
|
|
|
|
|
|
|
// ConsentGetResponseBody schema of the response body of the consent GET endpoint.
|
|
|
|
type ConsentGetResponseBody struct {
|
|
|
|
ClientID string `json:"client_id"`
|
|
|
|
ClientDescription string `json:"client_description"`
|
|
|
|
Scopes []Scope `json:"scopes"`
|
|
|
|
Audience []Audience `json:"audience"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// Scope represents the scope information.
|
|
|
|
type Scope struct {
|
|
|
|
Name string `json:"name"`
|
|
|
|
Description string `json:"description"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// Audience represents the audience information.
|
|
|
|
type Audience struct {
|
|
|
|
Name string `json:"name"`
|
|
|
|
Description string `json:"description"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// WellKnownConfiguration is the OIDC well known config struct.
|
|
|
|
//
|
|
|
|
// See https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata
|
|
|
|
type WellKnownConfiguration struct {
|
|
|
|
Issuer string `json:"issuer"`
|
|
|
|
JWKSURI string `json:"jwks_uri"`
|
|
|
|
|
|
|
|
AuthorizationEndpoint string `json:"authorization_endpoint"`
|
|
|
|
TokenEndpoint string `json:"token_endpoint"`
|
|
|
|
RevocationEndpoint string `json:"revocation_endpoint"`
|
2021-07-10 04:56:33 +00:00
|
|
|
UserinfoEndpoint string `json:"userinfo_endpoint"`
|
feat(oidc): add additional config options, accurate token times, and refactoring (#1991)
* This gives admins more control over their OIDC installation exposing options that had defaults before. Things like lifespans for authorize codes, access tokens, id tokens, refresh tokens, a option to enable the debug client messages, minimum parameter entropy. It also allows admins to configure the response modes.
* Additionally this records specific values about a users session indicating when they performed a specific authz factor so this is represented in the token accurately.
* Lastly we also implemented a OIDC key manager which calculates the kid for jwk's using the SHA1 digest instead of being static, or more specifically the first 7 chars. As per https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-web-key#section-8.1.1 the kid should not exceed 8 chars. While it's allowed to exceed 8 chars, it must only be done so with a compelling reason, which we do not have.
2021-07-03 23:44:30 +00:00
|
|
|
|
2021-07-10 04:56:33 +00:00
|
|
|
Algorithms []string `json:"id_token_signing_alg_values_supported"`
|
|
|
|
UserinfoAlgorithms []string `json:"userinfo_signing_alg_values_supported"`
|
feat(oidc): add additional config options, accurate token times, and refactoring (#1991)
* This gives admins more control over their OIDC installation exposing options that had defaults before. Things like lifespans for authorize codes, access tokens, id tokens, refresh tokens, a option to enable the debug client messages, minimum parameter entropy. It also allows admins to configure the response modes.
* Additionally this records specific values about a users session indicating when they performed a specific authz factor so this is represented in the token accurately.
* Lastly we also implemented a OIDC key manager which calculates the kid for jwk's using the SHA1 digest instead of being static, or more specifically the first 7 chars. As per https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-web-key#section-8.1.1 the kid should not exceed 8 chars. While it's allowed to exceed 8 chars, it must only be done so with a compelling reason, which we do not have.
2021-07-03 23:44:30 +00:00
|
|
|
|
|
|
|
SubjectTypesSupported []string `json:"subject_types_supported"`
|
|
|
|
ResponseTypesSupported []string `json:"response_types_supported"`
|
|
|
|
ResponseModesSupported []string `json:"response_modes_supported"`
|
|
|
|
ScopesSupported []string `json:"scopes_supported"`
|
|
|
|
ClaimsSupported []string `json:"claims_supported"`
|
|
|
|
|
|
|
|
RequestURIParameterSupported bool `json:"request_uri_parameter_supported"`
|
|
|
|
BackChannelLogoutSupported bool `json:"backchannel_logout_supported"`
|
|
|
|
FrontChannelLogoutSupported bool `json:"frontchannel_logout_supported"`
|
|
|
|
BackChannelLogoutSessionSupported bool `json:"backchannel_logout_session_supported"`
|
|
|
|
FrontChannelLogoutSessionSupported bool `json:"frontchannel_logout_session_supported"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// OpenIDSession holds OIDC Session information.
|
|
|
|
type OpenIDSession struct {
|
|
|
|
*openid.DefaultSession `json:"idToken"`
|
|
|
|
|
|
|
|
Extra map[string]interface{} `json:"extra"`
|
|
|
|
ClientID string
|
|
|
|
}
|