Angular-auth-oidc-client: CORS not enabled on Microsoft well known endpoints

[r4hulp]

My understanding might be totally wrong. But I wanted to have a discussion around the same.

I was testing the library from ng app hosted on localhost:4200. I am authenticating against Azure AD app (implicit flow). The auth flow gets stuck while getting signing keys.

It appears the some key discovery endpoints (e.g. jwks_uri: https://login.microsoftonline.com/common/discovery/keys, userinfo : https://login.microsoftonline.com/common/openid/userinfo ) do not have CORS enabled. We can not make an XHR request to retrieve information post callback.

Have you guys encountered this error before? am I missing something here?

This is the flow -

1. Login method initiates auth url generation
2. Round trip to auth url and retrieval of access token, state etc.
3. Get signing keys (throws CORS error).
4. Post validation, get user information (thrown CORS error after I explicitly tried to skip token validation)

Opened an issue since couldn't find better channel to talk.

error screenshot

Cheers,
Rahul.

[damienbod]

Could this be the same issue

https://github.com/IdentityModel/oidc-client-js/issues/249

[r4hulp]

Aha, that's the one @damienbod.

Now I am wondering, how would we validate response with jwt keys. We also would not get user information from the endpoint.

Would skipping validation and user info collection a right way to go ahead if at all we have to make this compatible with AAD?

Just thinking loud.

[damienbod]

No, you could download the well known endpoints and access these from the local service. These hardly every change. Seems like the User service from AAD needs the id_token for access which is incorrect...

[r4hulp]

The common .well-known point supports CORS. The only problem is other few discovery points. I guess I need to download response from https://login.microsoftonline.com/common/discovery/keys, host it somewhere on my backend and regenerate the entire well-known discovery object with new endpoints that support CORS. Also, the userinfo won't work for AAD.

Hacky way to get rid of userinfo requiring id_token is to wrap up custom user discovery endpoint that uses Microsoft Graph to retrieve user info on my own server and add that URL in my custom wellknown endpoint.

{
    authorization_endpoint: "https://login.microsoftonline.com/common/oauth2/authorize",
    token_endpoint: "https://login.microsoftonline.com/common/oauth2/token",
    token_endpoint_auth_methods_supported: [
        "client_secret_post",
        "private_key_jwt"
    ],
    jwks_uri: "<custom_keys_discovery_ep>",
    response_modes_supported: [
        "query",
        "fragment",
        "form_post"
    ],
    subject_types_supported: [
        "pairwise"
    ],
    id_token_signing_alg_values_supported: [
        "RS256"
    ],
    http_logout_supported: true,
    frontchannel_logout_supported: true,
    end_session_endpoint: "https://login.microsoftonline.com/common/oauth2/logout",
    response_types_supported: [
        "code",
        "id_token",
        "code id_token",
        "token id_token",
        "token"
    ],
    scopes_supported: [
        "openid"
    ],
    issuer: "https://sts.windows.net/{tenantid}/",
    claims_supported: [
        "sub",
        "iss",
        "cloud_instance_name",
        "cloud_graph_host_name",
        "aud",
        "exp",
        "iat",
        "auth_time",
        "acr",
        "amr",
        "nonce",
        "email",
        "given_name",
        "family_name",
        "nickname"
    ],
    microsoft_multi_refresh_token: true,
    check_session_iframe: "https://login.microsoftonline.com/common/oauth2/checksession",
    userinfo_endpoint: "<custom_userinfo_endpoint>",
    tenant_region_scope: null,
    cloud_instance_name: "microsoftonline.com",
    cloud_graph_host_name: "graph.windows.net"
}

Very hacky imho. :-(

[damienbod]

Agree, but I don't have any control over the server URLs

[damienbod]

closing this, repoen if you feel we need to do something here.

Thanks Damien

[g-guth]

@r4hulp did you find any solution on this?

[damienbod]

Yes, it was a bug in the http request, it now works

[g-guth]

is {tenant-speciefic}.well-known endpoints working via ajax request for AAD now (version 3.0.1)?

[aminebizid]

It works for .well-known but not for /discovery/keys

[BernhardRode]

What is your recommended solution for this?

[damienbod]

I download the 2 files and add them locally. Then use these. Here's an example:

https://github.com/damienbod/dotnet-template-angular/blob/master/dotnet-angular-azure-ad-oidc/ClientApp/src/app/app.module.ts

https://github.com/damienbod/dotnet-template-angular/blob/master/dotnet-angular-azure-ad-oidc/wwwroot/jwks.json

https://github.com/damienbod/dotnet-template-angular/blob/master/dotnet-angular-azure-ad-oidc/wwwroot/well-known-openid-configuration.json#L5

And the blog:

https://damienbod.com/2018/01/23/using-the-dotnet-angular-template-with-azure-ad-oidc-implict-flow/

Greetings Damien

[aminebizid]

@damien you don’t have any garentee that the endpoints and keys won’t change. Storing them locally may don’t work further.

[damienbod]

@aminebizid yes, this is a problem, and I don't now how often this changes,

What you could also do is use Azure AD B2C.

Here's an example. You need to configure this on Azure.
https://github.com/HWouters/ad-b2c-oidc-angular/blob/master/src/app/app.module.ts

[tommed]

Cross posted from the oidc-client repo
WARNING: Hacky idea alert!...

Manually fetch https://login.microsoftonline.com/common/discovery/keys and save to your local server. Then make a request to your own server by editing your oidc configuration. Ours looks like this:

export default {
  authority: 'https://login.microsoftonline.com/YOUR_TENANT_ID',
  client_id: 'MY_CLIENT_ID',
  resource: 'MY_CLIENT_ID',
  redirect_uri: 'http://localhost:8081/signin-oidc',
  response_type: 'id_token token',
  metadata: {
    // magic happens here!!
    jwks_uri: 'http://localhost:8081/jwks.json',
    authorization_endpoint: "https://login.microsoftonline.com/YOUR_TENANT_ID/oauth2/authorize",
    issuer: "https://sts.windows.net/YOUR_TENANT_ID/",
  },
  scope: 'openid',
  loadUserInfo: false,
  silent_redirect_uri: 'http://localhost:8081/silent-refresh-oidc.html',
  automaticSilentRenew: true,
  accessTokenExpiringNotificationTime: 30,
};

[Matt-J-Hosking]

They seem to have enabled CORS for their jwks endpoint now. Best to switch over or get caught out like we did with a cached copy of the old keys.

[giuseppe-bertucci]

they did only for the azure AD, b2c tenants still suffer the problem