OpenID Connect Metadata document doesn't reflect app-specific scopes?

[julealgon]

I read a bit on OpenID Connect Metadata endpoint here:

• https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc#fetch-the-openid-connect-metadata-document

I was trying to configure Swagger locally to rely on the discovery endpoint, however there doesn't seem to be a way to get Application-defined scopes with this mechanism. No matter how I call the endpoint (say, even if I pass the appid={applicaiton_id} querystring parameter), it always returns the same set of 4 default scopes for me:

"scopes_supported": [
  "openid",
  "profile",
  "email",
  "offline_access"
],

This information is basically useless to the client. Instead of returning these default scopes, I wanted it to return my API scope, access_as_user, instead. I plan on having multiple fine-grained scopes later and I would like to avoid having to hardcode them everywhere. Leveraging the discovery endpoint seemed like a good approach but it is useless if it does not return the data for the application.

Is it not possible to access the Azure AD OpenID Connect Metadata endpoint for this purpose? Every example I see of this mechanism on the internet lists the specific scopes supported for the given application. Do I need to call the endpoint using different parameters to obtain info on a specific application?

The URL I'm using currently is:
https://login.microsoftonline.com/{my_tenant_id}/v2.0/.well-known/openid-configuration?appid={my_application_id}

[nickludwig]

Hey @julealgon - thanks for the question. Going to investigate this and get back to you.

[julealgon]

Thanks @nickludwig . I posted basically the same question on Stackoverflow as well to see if it would get more traction. Feel free to answer there too:

• How do I include custom scopes for a given Application in Azure AD's OpenID Connect Metadata discovery endpoint?

[nickludwig]

We don't support this. The OIDC metadata endpoint just returns Azure AD's STS metadata. There's no concept of custom resources or custom scopes here. Since there's only one OIDC provider in this context (Azure AD), this means that regardless of what appid you pass as a parameter in the request to the metadata endpoint the supported_scopes will always be the same.

The reason passing an appid parameter (mind you, this is a non-standard extension) is supported is so custom signing keys can be discovered. So, the value of jwks_uri that's returned by the OIDC metadata endpoint is the only thing that can change based on what appid is passed as a parameter.

[julealgon]

The reason passing an appid parameter (mind you, this is a non-standard extension) is supported is so custom signing keys can be discovered.

Do you think it would be reasonable to also consider this parameter for scopes, as a new feature request for example? Surely if the accommodation was made for custom signing keys, it could be similarly done for custom scopes?

Otherwise, I just don't see the purpose of having OIDC metadata in the first place.

Still, I appreciate the response. For now, I'll have to stop using OIDC then and just hope that this is implemented in the future.

[maxisam]

I know MS don't support this but could you at least have groups scope if an app has group claim

I think this will cover 50% of use cases.

[IronSean]

Any update on the groups claim ask? Was it asked elsewhere?

[marcotielen]

Please vote here for support: #2803

@julealgon , @maxisam , @IronSean

[marcotielen]

It would be great if the use of custom scopes could be added. As you can see in the below link, Auth0 simply supports this. OpenID is rather useless without it, I feel. @nickludwig : is this up for reconsideration 2 years later?

https://auth0.com/docs/get-started/apis/scopes/sample-use-cases-scopes-and-claims#authenticate-a-user-and-request-standard-claims-and-custom-api-access