2021-05-05 05:06:05 +07:00
|
|
|
package oidc
|
|
|
|
|
|
|
|
import (
|
|
|
|
"github.com/ory/fosite/compose"
|
|
|
|
|
|
|
|
"github.com/authelia/authelia/internal/configuration/schema"
|
|
|
|
"github.com/authelia/authelia/internal/utils"
|
|
|
|
)
|
|
|
|
|
|
|
|
// NewOpenIDConnectProvider new-ups a OpenIDConnectProvider.
|
|
|
|
func NewOpenIDConnectProvider(configuration *schema.OpenIDConnectConfiguration) (provider OpenIDConnectProvider, err error) {
|
|
|
|
provider = OpenIDConnectProvider{
|
|
|
|
Fosite: nil,
|
|
|
|
}
|
|
|
|
|
|
|
|
if configuration == nil {
|
|
|
|
return provider, nil
|
|
|
|
}
|
|
|
|
|
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-04 06:44:30 +07:00
|
|
|
provider.Store, err = NewOpenIDConnectStore(configuration)
|
|
|
|
if err != nil {
|
|
|
|
return provider, err
|
|
|
|
}
|
2021-05-05 05:06:05 +07:00
|
|
|
|
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-04 06:44:30 +07:00
|
|
|
composeConfiguration := &compose.Config{
|
|
|
|
AccessTokenLifespan: configuration.AccessTokenLifespan,
|
|
|
|
AuthorizeCodeLifespan: configuration.AuthorizeCodeLifespan,
|
|
|
|
IDTokenLifespan: configuration.IDTokenLifespan,
|
|
|
|
RefreshTokenLifespan: configuration.RefreshTokenLifespan,
|
|
|
|
SendDebugMessagesToClients: configuration.EnableClientDebugMessages,
|
|
|
|
MinParameterEntropy: configuration.MinimumParameterEntropy,
|
|
|
|
}
|
2021-05-05 05:06:05 +07:00
|
|
|
|
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-04 06:44:30 +07:00
|
|
|
keyManager, err := NewKeyManagerWithConfiguration(configuration)
|
2021-05-05 05:06:05 +07:00
|
|
|
if err != nil {
|
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-04 06:44:30 +07:00
|
|
|
return provider, err
|
2021-05-05 05:06:05 +07:00
|
|
|
}
|
|
|
|
|
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-04 06:44:30 +07:00
|
|
|
provider.KeyManager = keyManager
|
2021-05-05 05:06:05 +07:00
|
|
|
|
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-04 06:44:30 +07:00
|
|
|
key, err := provider.KeyManager.GetActivePrivateKey()
|
|
|
|
if err != nil {
|
|
|
|
return provider, err
|
|
|
|
}
|
2021-05-05 05:06:05 +07:00
|
|
|
|
|
|
|
strategy := &compose.CommonStrategy{
|
|
|
|
CoreStrategy: compose.NewOAuth2HMACStrategy(
|
|
|
|
composeConfiguration,
|
|
|
|
[]byte(utils.HashSHA256FromString(configuration.HMACSecret)),
|
|
|
|
nil,
|
|
|
|
),
|
|
|
|
OpenIDConnectTokenStrategy: compose.NewOpenIDConnectStrategy(
|
|
|
|
composeConfiguration,
|
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-04 06:44:30 +07:00
|
|
|
key,
|
2021-05-05 05:06:05 +07:00
|
|
|
),
|
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-04 06:44:30 +07:00
|
|
|
JWTStrategy: provider.KeyManager.Strategy(),
|
2021-05-05 05:06:05 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
provider.Fosite = compose.Compose(
|
|
|
|
composeConfiguration,
|
|
|
|
provider.Store,
|
|
|
|
strategy,
|
|
|
|
AutheliaHasher{},
|
|
|
|
|
|
|
|
/*
|
|
|
|
These are the OAuth2 and OpenIDConnect factories. Order is important (the OAuth2 factories at the top must
|
|
|
|
be before the OpenIDConnect factories) and taken directly from fosite.compose.ComposeAllEnabled. The
|
|
|
|
commented factories are not enabled as we don't yet use them but are still here for reference purposes.
|
|
|
|
*/
|
|
|
|
compose.OAuth2AuthorizeExplicitFactory,
|
|
|
|
compose.OAuth2AuthorizeImplicitFactory,
|
|
|
|
compose.OAuth2ClientCredentialsGrantFactory,
|
|
|
|
compose.OAuth2RefreshTokenGrantFactory,
|
|
|
|
compose.OAuth2ResourceOwnerPasswordCredentialsFactory,
|
|
|
|
// compose.RFC7523AssertionGrantFactory,
|
|
|
|
|
|
|
|
compose.OpenIDConnectExplicitFactory,
|
|
|
|
compose.OpenIDConnectImplicitFactory,
|
|
|
|
compose.OpenIDConnectHybridFactory,
|
|
|
|
compose.OpenIDConnectRefreshFactory,
|
|
|
|
|
|
|
|
compose.OAuth2TokenIntrospectionFactory,
|
|
|
|
compose.OAuth2TokenRevocationFactory,
|
|
|
|
|
|
|
|
// compose.OAuth2PKCEFactory,
|
|
|
|
)
|
|
|
|
|
|
|
|
return provider, nil
|
|
|
|
}
|