How Intuit Uses OpenID 2.0 to Implement Single Sign On

Continued from page 1. 

Request: This is a 302 to Intuit OpenID end point.

GET https://vm-openid.intuit.com/OpenId/Provider?openid.ns=http://specs.openid.net/auth/2.0&openid.claimed_id=http://specs.openid.net/auth/2.0/identifier_select&openid.identity=http://specs.openid.net/auth/2.0/identifier_select&openid.return_to=http://localhost:8011/verifyopenid.htm&openid.realm=http://localhost:8011/verifyopenid.htm&openid.assoc_handle=EP0i!IAAAAB68uD0k0zW2ySHYPVsvjCC-g8VcuEmmxcy472UZoaOxQQAAAAFvg6JpHlxBnq5x1udeXl4940HcHZVMmjJ5Af0LEMNSSaI_7anMoCTU9Ne5rX44ZN92izQmTjRHNCcBjRI3Uc9e&openid.mode=checkid_setup&openid.ns.ext1=http://openid.net/srv/ax/1.0&openid.ext1.mode=fetch_request&openid.ext1.type.FirstName=http://axschema.org/namePerson/first&openid.ext1.type.LastName=http://axschema.org/namePerson/last&openid.ext1.type.Email=http://axschema.org/contact/email&openid.ext1.type.RealmId=http://axschema.org/intuit/realmId&openid.ext1.required=FirstName,LastName,Email,RealmId&openid.ext1.count.Email=3 HTTP/1.1
Host: vm-openid.intuit.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.110 Safari/537.36
Referer: http://localhost:8011/
Accept-Encoding: gzip, deflate, sdch
Accept-Language:...
Cookie:...

Response: This is a 302 back to the app end point Intuit OpenID end point mentioned in openid.return_to parameter

HTTP/1.1 302 Found
Cache-Control: private, s-maxage=0
Pragma: no-cache
Content-Length: 1525
Content-Type: text/html; charset=utf-8
Location: http://localhost:8011/verifyopenid.htm?openid.claimed_id=https%3A%2F%2Fvm-openid.intuit.com%2FIdentity-03d6580f-7fa0-4480-8aff-15cbeae3c270&openid.identity=https%3A%2F%2Fvm-openid.intuit.com%2FIdentity-03d6580f-7fa0-4480-8aff-15cbeae3c270&openid.sig=XZJHFdZsZRms12a9Vux6zr0gm%2BJDB4uXQgoGgUFFe0I%3D&openid.signed=claimed_id%2Cidentity%2Cassoc_handle%2Cop_endpoint%2Creturn_to%2Cresponse_nonce%2Cns.alias3%2Calias3.mode%2Calias3.type.alias1%2Calias3.value.alias1%2Calias3.type.alias2%2Calias3.value.alias2%2Calias3.type.alias3%2Calias3.value.alias3&openid.assoc_handle=EP0i%21IAAAAB68uD0k0zW2ySHYPVsvjCC-g8VcuEmmxcy472UZoaOxQQAAAAFvg6JpHlxBnq5x1udeXl4940HcHZVMmjJ5Af0LEMNSSaI_7anMoCTU9Ne5rX44ZN92izQmTjRHNCcBjRI3Uc9e&openid.op_endpoint=https%3A%2F%2Fvm-openid.intuit.com%2FOpenId%2FProvider&openid.return_to=http%3A%2F%2Flocalhost%3A8011%2Fverifyopenid.htm&openid.response_nonce=2016-04-11T23%3A33%3A48ZshWIZDhf&openid.mode=id_res&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.ns.alias3=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0&openid.alias3.mode=fetch_response&openid.alias3.type.alias1=http%3A%2F%2Faxschema.org%2FnamePerson%2Ffirst&openid.alias3.value.alias1=Bob&openid.alias3.type.alias2=http%3A%2F%2Faxschema.org%2FnamePerson%2Flast&openid.alias3.value.alias2=Smith&openid.alias3.type.alias3=http%3A%2F%2Faxschema.org%2Fcontact%2Femail&openid.alias3.value.alias3=kjonnala%2Beacct1%40gmail.com

Step 3: App validates the response claimed identity

This is where the XRDS document is returned from Intuit as a last-mile verification document.

Done by the “verifyOpenIDFromIntuit” function: here in the sample app

Request:

GET https://vm-openid.intuit.com/Identity-03d6580f-7fa0-4480-8aff-15cbeae3c270 HTTP/1.1
Accept: text/html; q=0.3, application/xhtml+xml; q=0.5, application/xrds+xml
Host: vm-openid.intuit.com
Connection: Keep-Alive

Response:

HTTP/1.1 200 OK
Cache-Control: private, s-maxage=0
Content-Type: application/xrds+xml; charset=utf-8
Content-Length: 685
<xrds:XRDS
    xmlns:xrds="xri://$xrds"
    xmlns:openid="http://openid.net/xmlns/1.0"
    xmlns="xri://$xrd*($v*2.0)">
    <XRD>
        <Service priority="10">

            <Type>http://specs.openid.net/auth/2.0/signon</Type>
            <Type>http://openid.net/extensions/sreg/1.1</Type>
            <Type>http://axschema.org/contact/email</Type>
           
            <URI>https://vm-openid.intuit.com/OpenId/Provider</URI>
        </Service>

        <Service priority="20">
            <Type>http://openid.net/signon/1.0</Type>
            <Type>http://openid.net/extensions/sreg/1.1</Type>
            <Type>http://axschema.org/contact/email</Type>
            <URI>https://vm-openid.intuit.com/OpenId/Provider</URI>
        </Service>

    </XRD>
</xrds:XRDS>

OpenID Connect vs OpenID 2.0

As the industry moved on to newer “authentication” standards, people realized that identity establishment and authentication could be connected more closely than the mechanism used between OAUTH 1.0a and OpenID 2.0. The problem was that both services were independent—they didn’t require each other in order to operate. Therefore, when OAUTH 2.0 came out, OpenID Connect was established as part of that flow as an add-on feature where user identity can be asserted and claims exchanged. In this transaction, the user information is usually returned as an encoded token meeting the JWT standards. The “sub” entity is the unique ID equivalent to the openid.claimed_id in OpenID 2.0.

Conclusion

This article should help clarify precisely what happens on the wire during an OpenID 2.0 handshake. If it seems intimidating, don’t worry—you don’t have to write these bits! There are OpenID libraries that live and breathe OpenID. For example, the sample code shown earlier is using the “openid4java” library. This post is intended to give you some insight into what is going on under the hood.

References

OpenID 2.0 spec

Intuit Developer OpenID docs

Sample Intuit App

Be sure to read the next Authentication article: Stormpath Launches Client API for Frontend Registration and Authentication

 

Comments (0)