4

I've got mod_auth_openidc working with Google and a hand rolled version of phpOIDC as my OP with the mod_auth_openidc as my identity provider.

My problem appears to be a bug in the Microsoft implementation.

mod_auth_openidc is a great mod and does quite a log of validation.

One of the things that is returned in a JWT is the "aud" parameter which is the audience.

According to the Open ID Connect spec:

aud REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value. It MAY also contain identifiers for other audiences. In the general case, the aud value is an array of case sensitive strings. In the common special case when there is one audience, the aud value MAY be a single case sensitive string.

My client id is 00000001234 (not my real ID, just an example).

I make it through the handshake and everything is groovy, I get my nonce "code" from Windows Live, then I exchange it for my token, but the token I get back has an "aud" value of:

00000000-0000-0000-0000-00000001234

mod_auth_openidc correctly checks the "aud" value in the returned token and responds with an error as the "aud" does not match the configured cliend_id, which is should, according to the spec.

My question is, other than not validating the audience of the token, is there any way to configure the app, in the MS Developer console so that it returns the client ID correctly for the "aud" value in the returned token?

Sans that, where is the best place to report such bug in their implementation?

Hans Z.
  • 50,496
  • 12
  • 102
  • 115
Severun
  • 2,893
  • 1
  • 16
  • 22
  • Are you sure you use the right `client_id`? My `client_id` looks like: `xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx". It authenticates against Azure AD, which sends it through to LIve ID, so not so much directly against LiveID. Perhaps that's different for you? – Hans Z. Jun 19 '15 at 06:01
  • Yup, I'm sure. The 00000001234 is what is shown in the app console on the MS Dev site. And if I try to use the client ID that's returned in the JWT aud parameter with the extra zeros prepended, I get an invalid client ID error when I send the user to the login.live.com site for validation, etc. – Severun Jun 19 '15 at 16:21
  • Can you give a pointer to the portal where you've registered the client? I'd like to try myself because apparently it is different than the Azure AD interface. – Hans Z. Jun 19 '15 at 16:39
  • The page I'm on is: https://account.live.com/developers/applications – Severun Jun 19 '15 at 18:14
  • https://account.live.com/developers/applications, this lists all of my applications that I've registered. This is where I added my app, and got the client_id w/out all the zeroes. – Severun Jun 19 '15 at 18:20
  • Here's the doc for signing in at MS https://msdn.microsoft.com/en-us/library/dn631824.aspx, it's linked to from the OneDrive page as how to authenticate to OneDrive. The doc also says they stuff the requesting domain into aud, which they do not, instead it's the client_id I got from the developers console w/ the zeros prepended. – Severun Jun 19 '15 at 18:30
  • Here's a link to an article that is linked to from OneDrive that provides a link to the first link above I listed, it also shows an example of a client id without the zeros. https://msdn.microsoft.com/EN-US/library/dn659751.aspx#Register_your_app_and_configure_its_settings – Severun Jun 19 '15 at 18:37
  • Oh, heres a good one. https://code.msdn.microsoft.com/windowsapps/AAL-Native-App-to-REST-de57f2cc At the bottom in the section titled "Security Considerations" it says: (tee hee). "JWT handler could be configured to skip audience verification and Issuer verification. The security implications of turning off these checks should be understood." – Severun Jun 19 '15 at 18:39

2 Answers2

2

Actually nowhere in the docs for login.live.com it says that MS Live is OpenID Connect compliant. It does mention that it has built its own SSO protocol on top of OAuth 2.0.

It seems that you've found out by-trial-and-error that MS Live supports important pieces of OpenID Connect (Discovery document on well-known location, JWKS URI, openid scope etc.), which is news to me in itself. But unfortunately it seems like one tiny thing is still missing... That's probably also the reason for not announcing OpenID Connect support for MS Live ID yet.

MS's OpenID Connect implementation in Azure AD is fully compliant already, Live ID not yet. I guess all you can do is bug MS.

Hans Z.
  • 50,496
  • 12
  • 102
  • 115
  • Dang, I believe your answer is correct, not the one I was hoping for, but correct. Isn't Azure AD just for your own accounts, kind of like Auth0? Do you know if Azure AD supports logging in w/ any MS Windows Live account? – Severun Jun 19 '15 at 20:16
  • Yes, you can signup for an Azure AD trial with your Live ID and it will authenticate you with Live ID. You'll need a payed-for subscription after the trial ends (although it appears that it keeps working after the trial period ends, you probably want to ensure that by paying...). – Hans Z. Jun 20 '15 at 06:53
  • I signed up for Azure AD and set it up added an app through azure, linked it to AD, it works great if I have the user in my Azure AD. I've also set up the app in Azure to use Windows live, etc, but I get the following error. User account 'my_windowslive_login' from external identity provider 'live.com' is not supported for application 'my_client_id'. The account needs to be added as an external user in the tenant. Please sign out and sign in again with an Azure Active Directory user account." – Severun Jun 23 '15 at 22:13
  • OK, so to get a Windows Live ID to work, you have to add them as a user to your "directory" and pick sourced from Microsoft account. It will do a pass through to Windows Live, but won't let you login, unless you manually add the user to your Azure AD account. It works to authenticate w/ mod_auth_openidc. Please let me know if you know a way to get it to let any Windows Live account through. – Severun Jun 23 '15 at 22:49
  • AFAICT things should become better with this: http://blogs.technet.com/b/ad/archive/2015/08/12/azure-ad-microsoft-account-preview-sign-in-personal-and-work-accounts-using-a-single-stack.aspx – Hans Z. Aug 13 '15 at 18:30
  • This looks promising. I followed the directions on https://azure.microsoft.com/en-us/documentation/articles/active-directory-v2-protocols/#openid-connect-with-oauth-code-flow to get this working, and all appears to go well until I get oidc_proto_validate_code_response: requested flow is "code" but no "access_token" parameter found in the code response when it hits my redirect URL – Severun Sep 11 '15 at 20:28
1

On MSA, 00000000-0000-0000-0000-00000001234 and 00000001234 are different identifiers for the same application. The new app portal (apps.dev.microsoft.com) prefers the 128 bit identifier (guid) and the old app portal ( account.live.com/developers/applications) prefers the older 64 bit identifier. The id_token will always contain the new identifier.

You can make the request client_id match the token 'aud' claim by using the new identifier format (ie 00000000-0000-0000-0000-00000001234).

The new identifiers were created so that the MSA and AAD identifiers would match.

Will B
  • 164
  • 3