Windows Live Open ID Connect/Oauth 2.0 How to use for SSO with Apache mod_auth_openidc

4
votes

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?

2
oauth-2.0openid-connectwindows-livemod-auth-openidc
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.
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
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.
The page I'm on is: account.live.com/developers/applications – Severun
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

2 Answers

2
votes

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.

1
votes

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.