Issue Summary

This is reproducible on Data Center: yes

When configuring JIT provisioning for OIDC authentication, and mapping custom claims to user data points, Atlassian app will fail to provision the user citing missing claims. 

As per OpenID specification, custom claims must be retrieved from /userinfo endpoint in case a token was obtained using response_type=code (which is what Atlassian apps do). Custom claims may be present on the id token if it was sourced using response_type=id_token, but for other cases userinfo endpoint must be used.

Atlassian SSO module exchanges a code it received from Oauth dance for a token, and then expects custom claims to be present on that token so it immediately tries to map the user but fails because custom claims are not present on the token.

See OpenID spec:

The Claims requested by the profile, email, address, and phone scope values are returned from the UserInfo Endpoint, as described in Section 5.3.2, when a response_type value is used that results in an Access Token being issued. However, when no Access Token is issued (which is the case for the response_type value id_token), the resulting Claims are returned in the ID Token.
In some cases, the End-User will be given the option to have the OpenID Provider decline to provide some or all information requested by RPs. To minimize the amount of information that the End-User is being asked to disclose, an RP can elect to only request a subset of the information available from the UserInfo Endpoint.

Also this: https://connect2id.com/products/server/docs/guides/requesting-openid-claims:

For all response_types that result in a access token being issued the consented claims will be made available for retrieval at the UserInfo endpoint. Only for response_type=id_token, which results in the issue of an ID token and no access token, will the claims be included in the ID token.

Steps to Reproduce

1. Configure OIDC authentication with JIT-enabled against a OIDC provider that fully conforms to OpenID spec (not Okta)
2. Try to login as a new user expected to be provisioned by JIT.

Expected Results

Atlassian SSO module should use /userinfo endpoint to resolve custom claims values during JIT, which would allow user to be provisioned.

Actual Results

2022-07-20 09:14:55,982+0000 http-nio-8080-exec-1 TRACE anonymous 554x290x1 1b1i5zt 172.29.211.189,172.50.0.2 /plugins/servlet/external-login/1 [c.a.p.a.i.web.oidc.OidcAuthenticationRequestFactory] Effective OIDC scopes for auth request to IdP [1] are: [[openid, groups, email, profile]]2022-07-20 09:14:55,982+0000 http-nio-8080-exec-1 DEBUG anonymous 554x290x1 1b1i5zt 172.29.211.189,172.50.0.2 /plugins/servlet/external-login/1 [c.a.p.a.i.web.oidc.OidcAuthenticationRequestFactory] Prepared OpenID Authentication request: scope=openid+groups+email+profile&response_type=code&redirect_uri=https%3A%2F%2Flinux-21285.prod.atl-cd.net%2Fjira%2Fplugins%2Fservlet%2Foidc%2Fcallback&state=vMRUVZLomJ91bHEorpVfZC5_1im6414Gcp2tfNziXME&nonce=OD4wL8KcIvKX6O7vxAoOHnJHXC8G321dfaCwuuMsIvQ&client_id=jira

2022-07-20 09:15:07,038+0000 http-nio-8080-exec-10 DEBUG anonymous 555x291x1 1b1i5zt 172.29.211.189,172.50.0.2 /plugins/servlet/oidc/callback [c.a.p.a.i.web.oidc.OidcConsumerServlet] Looking for a username in ID token by checking custom claim [sub]2022-07-20 09:15:07,038+0000 http-nio-8080-exec-10 TRACE anonymous 555x291x1 1b1i5zt 172.29.211.189,172.50.0.2 /plugins/servlet/oidc/callback [c.a.p.a.i.w.u.i.jit.mapping.OidcUserDataFromIdpMapper] Claims received in response for IdP: [at_hash, sub, aud, iss, exp, nonce, iat]2022-07-20 09:15:07,039+0000 http-nio-8080-exec-10 ERROR anonymous 555x291x1 1b1i5zt 172.29.211.189,172.50.0.2 /plugins/servlet/oidc/callback [c.a.p.a.i.web.filter.ErrorHandlingFilter] [UUID: a43c71e5-4bec-4aae-85f8-d30b909775ac] Claim [name] could not be foundcom.atlassian.plugins.authentication.impl.web.usercontext.impl.jit.JitException: Claim [name] could not be found 

Workaround

Most OIDC Providers either have custom claims to be present on ID token regardless of the response type (which technically not conforming to OpenID specification), or can be configured to add custom claims to ID tokens regardless of response type used. 

Check with your OIDC IDP configuration on if such configuration can be enabled.