[
https://issues.apache.org/jira/browse/NIFI-4210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120851#comment-16120851
]
ASF GitHub Bot commented on NIFI-4210:
--------------------------------------
Github user alopresto commented on the issue:
https://github.com/apache/nifi/pull/2047
I continued reviewing with a custom IdP from Auth0. This provider can
integrate with other providers, including Google, Facebook, etc. and also have
its own custom users stored locally. @mcgilman and I were able to receive a
success response from Auth0 for a custom user, but the token signature could
not be validated. We traced this to determine that on startup, when the
`TokenValidator` is initialized, if no
`nifi.security.user.oidc.preferred.jwsalgorithm` is present in
`nifi.properties`, the first value of `id_token_signing_alg_values_supported`
in the response from the OpenID Connect Discovery Document URI is used. In
Auth0's case, this was `HS256` as opposed to `RS256`, but the tokens returned
were signed with `RS256`, resulting in NiFi returning an error "Unable to
exchange authorization for ID token: Unable to parse the response from the
Token request: Signed JWT rejected: Another algorithm expected, or no matching
key(s) found".
The Auth0 OIDC Discovery Document response:
```
{"issuer":"https://apachenifi.auth0.com/","authorization_endpoint":"https://apachenifi.auth0.com/authorize","token_endpoint":"https://apachenifi.auth0.com/oauth/token","userinfo_endpoint":"https://apachenifi.auth0.com/userinfo","mfa_challenge_endpoint":"https://apachenifi.auth0.com/mfa/challenge","jwks_uri":"https://apachenifi.auth0.com/.well-known/jwks.json","registration_endpoint":"https://apachenifi.auth0.com/oidc/register","scopes_supported":["openid","profile","offline_access","name","given_name","family_name","nickname","email","email_verified","picture","created_at","identities","phone","address"],"response_types_supported":["code","token","id_token","code
token","code id_token","token id_token","code token
id_token"],"response_modes_supported":["query","fragment","form_post"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["HS256","RS256"],"token_endpoint_auth_methods_supported":["client_secret_basic","client_secret_post"],"claims_supported":["aud","auth_time","created_at","email","email_verified","exp","family_name","given_name","iat","identities","iss","name","nickname","phone_number","picture","sub"]}
```
We decided to change the initialization logic to default to `RS256` as it
is required by the [OpenID Connect
Specification](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata)
to always be present in this response.
> id_token_signing_alg_values_supported
> REQUIRED. JSON array containing a list of the JWS signing algorithms (alg
values) supported by the OP for the ID Token to encode the Claims in a JWT
[JWT]. **The algorithm RS256 MUST be included**. The value none MAY be
supported, but MUST NOT be used unless the Response Type used returns no ID
Token from the Authorization Endpoint (such as when using the Authorization
Code Flow).
I manually provided `RS256` as a configuration value for
`nifi.security.user.oidc.preferred.jwsalgorithm` in `nifi.properties` and was
able to successfully sign in as the user.
> Add OpenId Connect support for authenticating users
> ---------------------------------------------------
>
> Key: NIFI-4210
> URL: https://issues.apache.org/jira/browse/NIFI-4210
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Core UI
> Reporter: Matt Gilman
> Assignee: Matt Gilman
>
> Add support for authenticating users with the OpenId Connection
> specification. Evaluate whether a new extension point is necessary to allow
> for a given provider to supply custom code for instance to implement custom
> token validation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
