As part of exercise to test the extensibility of OpenID Connect to other protocols than HTTP, we have created a custom scheme binding. This is still a rough sketch but should give you some ideas on what it is. It may seem to be a bit of stretch, but has a niche characteristics that it does not "leak" information to external OPs.
There will be a companion RP side as well, which would be a more normal case.
Connector Corner: Accelerate revenue generation using UiPath API-centric busi...
Smartphone Native Application OP
1. Smartphone Native Application OP
OpenID Connect application URL scheme binding
@_nat
@eijima
IdCon #11 IDENTITY CONFERENCE
February 3, 2012
2. Entities
User Info
RP(Web Application)
(Client) Request Authorization
OP(Smartphone Native Application)
(Authorization Server, Resource Server)
Access Token
Authenticate User
User-Agent(Smartphone Native Application)
Request Service
Smartphone
End-User
(Resource Owner)
3. 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.
4. User Experience – Client(RP) Registration -
1. User accesses RP by User-Agent 2. OP app starts and returns “not registered” 4. OP application starts 5. OP application returns
Tap “Kantan-Login” button error via User-Agent. OP asks User for the consent successful response via
* RP requests authorization 3. RP requests client registration via User- of RP registration User-Agent
Agent 6. RP re-requests
authorization
5. User Experience – Authorization & UserInfo Request -
1. User accesses RP by User-Agent 2. OP app asks User for the 3. OP app returns Access Token 5. RP receives the Access Token
Tap “Kantan-Login” button consent of PII transmission to to RP via User-Agent User logs in RP
RP 4. RP sends Access Token to RP
and requests OP to transmit
UserInfo via User-Agent.
6. 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.
8. 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/request
2. 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 File
5. 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=af0ifjsldkj
7. 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.
10. 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.
12. 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.
13. Open Isuue
Client 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