IDENTITY CONFERENCEIdCon #11

Smartphone Native Application OPOpenID Connect application URL scheme binding

February 3, 2012

@_nat@eijima

EntitiesOP(Smartphone Native Application)(Authorization Server, Resource Server)

End-User(Resource Owner)

RP(Web Application)(Client)

User-Agent(Smartphone Native Application)

Smartphone Request Service

Request Authorization

Authenticate UserAccess Token

User Info

Application URL Scheme• We can bind a Smartphone (iOS SDK, Android SDK) native application to a custom URL scheme.• That scheme can be used to launch the application from either a browser or from another application on the Smartphone.

User Experience – Client(RP) Registration -

1. User accesses RP by User-Agent Tap “Kantan-Login” button * RP requests authorization

4. OP application starts OP asks User for the consent of RP registration2. OP app starts and returns “not registered” error via User-Agent.3. RP requests client registration via User-Agent

5. OP application returns successful response via User-Agent6. RP re-requests authorization

User Experience – Authorization & UserInfo Request -

1. User accesses RP by User-Agent Tap “Kantan-Login” button 2. OP app asks User for the consent of PII transmission to RP5. RP receives the Access Token User logs in RP

3. OP app returns Access Token to RP via User-Agent4. RP sends Access Token to RP and requests OP to transmit UserInfo via User-Agent.

Protocol Design• Only support Implicit Grant

– Client authentication• client_id == FQDN of the Client (RP)• client_secret is not used. The implicit grant type does not include client authentication.

• Request from RP to OP– End point(request) URI := openid://path

• e.g.) openid://host/path?query– Request parameters

• Smartphone applications can receive only request URL string from RP via User-agent.– All requests require a redirect_uri (or response_uri) parameter. These URI must be HTTPS.

• All requests must be sent by one of the following three methods. (like an authorization request of the OpenID Connect Standard)– Simple Request Method– Request Parameter Method– Request File Method

• Response from OP to RP– OP send response to redirect_uri(or response_uri) by http GET method via User-agent. Both successful and error response must be fragment-encoded.– RP returns a page including a javascript code. The javascript code read the fragment and post the fragment to RP.

• Open Issue– How to generate user_id of the ID Token? The user_id must be unique and never reassigned identifier among all OP apps.

Authorization Request & Response Sequence• http://www.websequencediagrams.com/?

lz=cGFydGljaXBhbnQgRW5kVXNlciBhcyB1CgANDFJQXG5DbGllbnQgYXMgcnAAEA1Vc2VyQWcAFQd1YQAsDU9QXG5TbWFydHBob25lQXBwIGFzIG9wCgpub3RlIGxlZnQgb2YgcnA6IFJlcXVlc3QgRmlsZSBNZXRob2QKCnJwLT51YTogcgAWB0F1dGhvcml6YXRpb25cbm9wZW5pZDovL2F1dGg_XG4AIAdfdHlwZT10b2tlblxuJmMAgTMFX2lkPXJwLmNvbVxuJnJlZGlyZWN0X3VyaT1odHRwczovLwAYBgBGBS9jYWxsYmFja1xuJnNjb3BlPQBkBlxuJm5vbmNlPW4tMFM2X1d6QTJNagBLBQByBgA3GACBOAcKCnVhLT5vcACBORcKCm9wLT5ycDogZmV0Y2gAgWwJZmlsZQpycC0ALQ4AEQUALQV1OiBhdXRoZW50aWNhdGUgJgCCJgljb25zZW50CnUANQcACAgAMQZhOiBBY2Nlc3MgVG9rZW4gaW4gZnJhZ21lbgCDDwYAghoLXG4AggocI1xuYQBEBV8Agm8FPWpIa1dFLi4uNUtGMFlcbiYAgwUFAIMPBkJlYXJlclxuAIIFBnJwOiAAghoWAIMaBgCDfAUAg3wGc2NyaXAAgjsHdWE6IHBhcnNlAIEmCmJ5ABUNAFEIIHBvc3QAgVgOdG8gUlAAJQsAWQk&s=modern-blue

Authorization Request & Response Steps – Case: Request File Method -1. RP(Client) redirects the User-Agent on the End-User’s smartphone to Authorization Endpoint with “request_uri” parameter.

– Authorization Endpoint URI is Application URL scheme:”openid” openid://auth?request_uri=https://rp.com/auth/request2. OP application on the End-User’s smartphone starts via Authorization Endpoint(= Application URL scheme: “openid”)3. OP application fetches the Request File from “request_uri”4. RP returns the Request File5. OP application authenticates the End-User and obtains the End-User Consent/Authorization.6. OP returns a response to the RP’s “redirect_uri” via User-Agent. Response parameters must be fragment-encoded.– https://rp.com/auth/callback#access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y &token_type=Bearer &id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9zZ XJ2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiaHR0c DpcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0vzDH3T1 G3liaTNOrfaeWYjuRCEPNXVtaazNQ &state=af0ifjsldkj7. RP returns the script to the User-Agent.8. The script runs in the User-Agent and posts the OP’s response(access_token, id_token etc.) to the RP.

UserInfo Request & Response Sequence• http://www.websequencediagrams.com/?

lz=cGFydGljaXBhbnQgUlBcbkNsaWVudCBhcyBycAoAEQxVc2VyQWcAFQd1YQAPDU9QXG5TbWFydHBob25lQXBwIGFzIG9wCgpub3RlIGxlZnQgb2YgcnA6IFJlcXVlc3QgRmlsZSBNZXRob2QKCnJwLT51YTogcgAWB1VzZXJJbmZvIHcvAAwIX3VyaSBcbm9wZW5pZDovL3VzZXJpbmZvPwAVCz1odHRwczovL3JwLmNvbQAbCS8AUQcKCnVhLT5vcAAGY29wLT5ycDogZmV0Y2gAgU8JZmlsZQpycC0Adw5maWxlXG574oCcYWNjZXNzX3Rva2Vu4oCdOiAiU2xBVjMyaGtLRyIsIOKAnHNjaGVtYQAXBeKAnACCCAbigJ0AFwVyZXNwb25zZV91cmkAGggAgXgaACYGfQCBJQZvcDogZW5jcnlwAIJvDlJQJ3MgcHVibGljIGtleQCBUgZ1YToAgxgKaW4gZnJhZ21lbgCDXQYAeQtcbgBeICNKV1RfZW5jb2RlZF8Ag20IAIMgBnJwOiAAgR0gAIQ0BQCENAZzY3JpcACDWgd1YTogcGFyc2UAgRAWYnkAIQ0AYQggcG8AhG4MABwKAFsJAIUiBXJwOiBkZQCCHA4&s=modern-blue

UserInfo Request & Response Messages• UserInfo Request parameters

– The following parameters are defined in addition to what ware defined by the OpenID Connect Messages 1.0.• response_uri

– A response URI where the response will be sent.• request

– A JWT encoded Request Object. For Request Parameter Method.• request_uri

– The URI of the Request File. For Request File Method.• UserInfo Request Object

– The Request Object must be JWT encoded. It may be JWS signed and/or JWE encrypted.– Sample JSON

• {“access_token”: "SlAV32hkKG", “schema”: “openid”, “response_uri”: “https://example.com/userinfo/response”}• UserInfo Response

– The response must be JWT that is JWS signed with OP’s key and JWE encrypted with RP’s key.– Error response parameters

• …• Security considerations

– Because of the security weaknesses associated with the URI method (see Section 4), including the high likelihood that the URL containing the access token will be logged.The Client SHOULD construct the request using the Request Parameter Method with JWE encrypted or the Request File Method.

Dynamic Client Registration Request & Response Sequence• http://www.websequencediagrams.com/?

lz=cGFydGljaXBhbnQgRW5kVXNlciBhcyB1CgANDFJQXG5DTGllbnQgYXMgcnAAEA1Vc2VyQWcAFQd1YQAsDU9QXG5TbWFydHBob25lQXBwIGFzIG9wCgpub3RlIGxlZnQgb2YgdTogUmVxdWVzdCBGaWxlIE1ldGhvZApycC0-dWE6IHIAFQdyZWdpc3Qgdy8ACghfdXJpXG5vcGVuaWQ6Ly8AGgY_ABILPWh0dHA6Ly9ycC5jb20AGgcvAEkHCnVhLT5vcABKFnNwb25zZV91cmwAJjtvcC0-cnA6IGZldGNoAIE-CWZpbGUKcnAtAG8OZmlsZSAobXVzdCBiZSBKV1Mgc2lnbmVkIEpXVClcbnsidHlwZSI6ImFzc29jaWF0ZSIsXG4gInJlZGlyZWMAggYFcyI6Imh0dHBzAIFoCmNhbGxiYWNrIixcbiJqd2tfdXJsABQScHVibGljX2tleS5qdwAmBgCBdwtpAEUSAIJACQCCIQYifQCBZgVvcDogdmVyaWZ5IEpXUwCBeQV1AIM0CmNvbnNlbnQKdQCBcgcACAgAMggAg1cHUlAAMwYAg3MFAIMABiBjbGllbnRfaWQgaW4gZnJhZ21lbnRcbgB3HiMALQk9AIN5BgCDawVycDogAIEvHgCDFQZ1YTogc2NyaXAAhCEGdWE6IHBhcnNlAHYJIGJ5ABUMcnA6IHBvc3QAgSELABcKAEkJ&s=modern-blue

Dynamic Client Registration Request & Response Messages• Dynamic Client Registration Request parameters

– The following parameters are defined in addition to what ware defined by the OpenID Connect Dynamic Client Registration 1.0.– response_uri

• REQUIRED. A response URI where the response will be sent.– request

• A JWT encoded Request Object. For Request Parameter Method.– request_uri

• The URI of the Request File. For Request File Method.• Dynamic Client Registration Request Object

– Request Object must be JWT that is JWS signed with RP’s key.– The JWK which the “jwk_url” parameter in the JSON points must be same as the JWK which the “jku” parameter in the JWS header points. – Sample JSON

• { “type”: ”client_associate”, “redirect_uris”: “https://example.com/callback”, “logo_url”: “https://example.com/logo.png”, “jwk_url”=“https://example.com/public_key.jwk”, “userinfo_encrypted_response_algs”: “RSA1_5 A128CBC” “response_uri”: “https://example.com/regist/response” }• Dynamic Client Registration Response parameters

– client_id == FQDN of the Client (FQDN of “response_uri”?)– client_secret is not used. The implicit grant type does not include client authentication.– Sample response: https://example.com/regist/response#client_id=example.com

• Open issues– When a different business entity shares the same FQDN(==client_id), e.g. users of same hosting service, one registration makes it unable to perform registration of another side.

Open IsuueClient Registration Authority – Embedded in OP application vs Central RA• Central Client Registration Authority

– Advantage• Clients(RPs) register their parameters to the Central Client Registration Authority.There is no necessity of changing current draft of the OpenID Connect Dynamic Client Registration specification.• There is no restriction in the value of client_id.• The End-User does not need to care about the Client Registration.

– But• OP application must query the Central RA to get the registration information of Clients(RPs).• Must manage the Central RA

IDENTITY CONFERENCEIdCon #11

Thanks!