Does LWA's token endpoint return an OpenID Connect id_token? (federating LWA into Microsoft Entra External ID)

I’m integrating Login with Amazon as a federated OpenID Connect identity provider for Microsoft Entra External ID (CIAM). Entra’s “Custom OpenID Connect” provider option expects an OIDC-compliant IdP, and I’ve run into what looks like a protocol mismatch I’d like to confirm from the Amazon side before I architect around it.

My LWA Security Profile is set up correctly (client ID/secret issued, Allowed Return URLs configured to Entra’s federation redirect), so this isn’t a config-typo question — it’s about LWA’s protocol surface:

  1. id_token — Does LWA’s token endpoint (api amazon com / auth / o2 / token) ever return an OIDC id_token in the authorization-code-grant response, or is it strictly access_token (+ optional refresh_token)? Entra’s code flow requires an id_token to validate the federated sign-in.

  2. Discovery document — Is there any .well-known / openid-configuration endpoint published for LWA? I haven’t been able to locate one.

  3. openid scope — Is the openid scope supported, or are scopes limited to profile / profile:user_id / postal_code?

If the answer is “access_token only, no id_token, no discovery document, no openid scope” — i.e. LWA is OAuth 2.0 but not OpenID Connect — that’s a perfectly clear answer and I’ll plan accordingly. I just want to confirm it’s by design rather than something I’ve misconfigured.

If there is an OIDC-compliant mode or endpoint I’ve missed, a pointer to the docs would be hugely appreciated. Thanks!

Hi @rgsiiiya

Welcome to Amazon Developer Community !!

Your suspicion is correct. Login with Amazon (LWA) is OAuth 2.0 only - it is not an OpenID Connect (OIDC) provider. Specifically:

  1. No id_token - LWA’s token endpoint (api.amazon.com/auth/o2/token) returns only an access_token (and optionally a refresh_token) in the authorization code grant response. It does not issue an id_token.
  2. No discovery document - There is no .well-known/openid-configuration endpoint published for LWA.
  3. No openid scope - LWA’s supported scopes are limited to profile, profile:user_id, and postal_code. The openid scope is not supported.

This is by design - LWA implements the OAuth 2.0 authorization framework for granting access to customer profile data, but does not implement the OpenID Connect layer on top of it.

Options for integrating with Microsoft Entra External ID:
Since Entra’s “Custom OpenID Connect” provider requires a compliant OIDC IdP (with id_token, discovery document, etc.), you have a few architectural options:

  1. Use Amazon Cognito as a bridge - Set up an Amazon Cognito User Pool with LWA configured as a social identity provider. Cognito is OIDC-compliant (it publishes .well-known/openid-configuration and issues id_tokens). You can then point Entra at your Cognito User Pool as the OIDC IdP.
  2. Build a thin OIDC proxy - Create a lightweight service that wraps LWA’s OAuth 2.0 flow and presents an OIDC-compliant interface (discovery document, id_token generation using the profile data from LWA’s /user/profile endpoint). This is more work but avoids the Cognito dependency.
  3. Use Entra’s custom authentication extensions - If Entra supports a custom OAuth 2.0 provider (not just OIDC), you may be able to use a token exchange or custom claims provider to bridge the gap. Check Entra’s documentation for “custom identity provider” options beyond strict OIDC.

Hope this clarifies things!

Warm Regards,
Ivy