[Openid-specs-native-apps] native app validation
Emily Xu
exu at vmware.com
Tue Jul 8 12:44:18 UTC 2014
So if we continue to use the overloaded OAuth2 scope, for the use case I mentioned, the AppInfo would be something like this:
{
"name": "TestApp1",
"type": "native",
"scope": "urn:oauth:testapp1",
"default_scopes": ["rs1:read rs1:write rs2:install rs2:delete"],
"icon_uri": "http://www.example.com/pic3.png<https://urldefense.proofpoint.com/v1/url?u=http://www.example.com/pic3.png&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=IOcogj9VVYIVG08Q5exet3ZcjD14eQZ74sW8TzsMe2w%3D%0A&s=53243901b8e92d8b52aacc98e188eaed013ff064f0df481ed2bfadfc9701efe7>",
"custom_uri": "testapp3://callback-uri/"
"bundle_id": "oejfiejfefjpefefefeifie"
}
When TA sends request to AS to obtain access token to access rs1 for TestApp1, the request will contain:
refresh_token=<TA's primary refresh token>
scope=urn:oauth:testapp1 rs1:read rs1:write
When TA sends request to AS to obtain access token to access rs2 for TestApp1, the request will contain:
refresh_token=<TA's primary refresh token>
scope=urn:oauth:testapp1 rs2:install rs2:delete
If TA sends request to AS with scope=urn:oauth:testapp1 only, AS will use something preconfigured for TestApp1 to issue the access token.
Is my understanding correct?
Thanks,
Emily
From: John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>
Date: Monday, July 7, 2014 10:17 AM
To: Emily Xu <exu at vmware.com<mailto:exu at vmware.com>>
Cc: Paul Madsen <paul.madsen at gmail.com<mailto:paul.madsen at gmail.com>>, "openid-specs-native-apps at lists.openid.net<mailto:openid-specs-native-apps at lists.openid.net>" <openid-specs-native-apps at lists.openid.net<mailto:openid-specs-native-apps at lists.openid.net>>
Subject: Re: [Openid-specs-native-apps] native app validation
That is one of the slightly less optimal things about OAuth in that scope tends to be quite overloaded.
The scope strings need to to combine identifying the resource server and the permissions for the resource.
Currently you need to have a scope names like "rs1:read", "rs1:write" and "rs2:install" etc.
This gets a bit messy when we have API with standardized scope names that might be applied across multiple resources.
In "OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution"
https://datatracker.ietf.org/doc/draft-bradley-oauth-pop-key-distribution<https://urldefense.proofpoint.com/v1/url?u=https://datatracker.ietf.org/doc/draft-bradley-oauth-pop-key-distribution&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=YD4izd0vHWn4h5jDRLlW71DAb4lHkMsV8Vi7e05BQgg%3D%0A&s=6acacf535eecbdb26c4b29a8f6be4658917af9b6e0d262bdf255a6e19f68ad5c>
We introduced a new parameter for the token endpoint Audience "aud" this allows the RS to be separately identified.
In that case it is because you may have a refresh token that might contain grants for RS1 and RS2 but if you are using symmetric proofs the proof key in the token needs to be encrypted to the RS, so you need to be explicit about what RS you want an access token for.
I am thinking about introducing the "aud" parameter for requesting a id_token to avoid further overloading scope when the client is requesting a id_token.
In that case the scope would contain "id_token" and the "aud" would be the well known ID of the AS the client intends to send the id_token to (typically the "iss" value the AS uses).
John B.
On Jul 7, 2014, at 10:56 AM, Emily Xu <exu at vmware.com<mailto:exu at vmware.com>> wrote:
Now I see what my confusion is. In your view, the "scope" scope is to identify the client app. However, I thought it is to identify the Resource Server that the client app is trying to access.
Now consider this situation, a client app (TestApp1), needs access to Resource Server 1 (RS1)with access token scope read and write. The same app also needs to access Resource Server 2 (RS2) with access token scope install and delete. RS1 and RS2 both can validate access tokens issued by the same AS. In this use case, what should be the value for scope, default_scopes, and how do we identify RS1 and RS2 with their own token scope?
Thanks,
Emily
From: John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>
Date: Monday, July 7, 2014 6:57 AM
To: Paul Madsen <paul.madsen at gmail.com<mailto:paul.madsen at gmail.com>>
Cc: Emily Xu <exu at vmware.com<mailto:exu at vmware.com>>, "openid-specs-native-apps at lists.openid.net<mailto:openid-specs-native-apps at lists.openid.net>" <openid-specs-native-apps at lists.openid.net<mailto:openid-specs-native-apps at lists.openid.net>>
Subject: Re: [Openid-specs-native-apps] native app validation
Yes,
The perhaps confusingly named "scope" paramater contains the identifier for the client app that is passed to the Token endpoint so that the AS knows what the app is.
Based on the bundle id and custom uri the TA validates the app and includes the value in its token request for the app.
There are some use cases where the TA is requesting a token for the app based on invocation from some sort of native desktop app.
In that case it may need to also request additional scopes when requesting a token.
The "scope" scope is required, the default_scopes are optional and used if the app itself is not asking for some more specific scopes.
John B.
On Jul 7, 2014, at 5:59 AM, Paul Madsen <paul.madsen at gmail.com<mailto:paul.madsen at gmail.com>> wrote:
hi Emily, my understanding is that the scope parameter serves to identify the application and distinguish it from others. But there may well be more specific sets of operations for each application, eg read vs write etc.
Consequently the TA may need to be able to specify these additional scopes in its requests of the AS. The default_scopes array informs the TA of what these additional 'scopes' are. The TA would insert these as additional (space delimited) parameters when it asked the AS for a secondary access token
I suspect the value of the mechanism is in supporting 3rd party ASs.
John?
paul
On 7/7/14, 12:39 AM, Emily Xu wrote:
Hi John,
I don't think I follow you completely on this. What is the difference between scope and default_scopes? Why the values for the two are so different?
I assume one of them will contain list of resource servers that this native app could ask token for. The default scope could be the one if TA pushes access token to client app (without client app asks first), token for that scope will be returned.
Another question, who should be the one who validates the native app (custom url and bundle id)? I assume AS should do the validation. If this is true, then custom url and bundle id should be passed to AS by TA when asking access token for native app.
Thanks,
Emily
From: John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>
Date: Sunday, July 6, 2014 4:49 PM
To: Emily Xu <exu at vmware.com<mailto:exu at vmware.com>>
Cc: "openid-specs-native-apps at lists.openid.net<mailto:openid-specs-native-apps at lists.openid.net>" <openid-specs-native-apps at lists.openid.net<mailto:openid-specs-native-apps at lists.openid.net>>
Subject: Re: native app validation
Looking at this again the scope value returned from app_info is a special scope that identifies the client app making the request to the TA.
It is a single string value that gets added to the scope parameter in the request.
I have updated the text to make that clearer.
I added a new parameter that allows the app_info endpoint to specify default scopes for applications. This can be used when the TA is requesting a token to push to the app without
having the app call the TA first.
So to revisit your question.
It would look like
"apps": [
{
"name": "TestApp1",
"type": "native",
"scope": "urn:oauth:testapp1",
"default_scopes": ["com.testrs1"],
"icon_uri": "http://www.example.com/pic1.png<https://urldefense.proofpoint.com/v1/url?u=http://www.example.com/pic1.png&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=IOcogj9VVYIVG08Q5exet3ZcjD14eQZ74sW8TzsMe2w%3D%0A&s=8d88d0f30400fc8e2ebb6da27f97087042901f488d07933245f94322b9d22477>",
"custom_uri": "testapp1://callback-uri/",
"bundle_id": "nkdf9hfknfih9enfen"
},
{
"name": "TestApp2",
"type": "native",
"scope": "urn:oauth:testapp1",
"default_scopes": ["com.testrs2"]
"icon_uri": "http://www.example.com/pic2.png<https://urldefense.proofpoint.com/v1/url?u=http://www.example.com/pic2.png&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=IOcogj9VVYIVG08Q5exet3ZcjD14eQZ74sW8TzsMe2w%3D%0A&s=b773acca3bc95051fd4f690cec8fe08f7131a2dcc3b6761c224a77be30b92571>",
"custom_uri": "testapp2://callback-uri/"
"bundle_id": "jdfejfemfefpoemkflen"
}
]
What if a third native app (TestApp3) needs token to access to TestRS1 and TestRS2. What the AppInfo will look like?
{
"name": "TestApp3",
"type": "native",
"scope": "urn:oauth:testapp3",
"default_scopes": ["com.testrs1"," com.testrs2"],
"icon_uri": "http://www.example.com/pic3.png<https://urldefense.proofpoint.com/v1/url?u=http://www.example.com/pic3.png&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=IOcogj9VVYIVG08Q5exet3ZcjD14eQZ74sW8TzsMe2w%3D%0A&s=53243901b8e92d8b52aacc98e188eaed013ff064f0df481ed2bfadfc9701efe7>",
"custom_uri": "testapp3://callback-uri/"
"bundle_id": "oejfiejfefjpefefefeifie"
}
An app may request other scopes in it's call to the TA, and the AS would need to validate those.
It may be that we should rename scope to something like app_id_scope or something like that to make the use clearer.
I didn't change the name just clarified the use.
John B.
On Jul 5, 2014, at 10:21 AM, John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>> wrote:
Yes that is correct.
The one thing that your example points out that needs to be clarified is what separator to use between scopes in the scope parameter.
I had assumed that it would be the same as OAuth being a space separated list.
The other alternative to be more JSON friendly is to make it an array.
There are advantages both ways. I don't think comma separated is a good idea.
Do people have a view on this. I can update the text for the parameter today to make it clear one way or the other.
I think people have used space separated in the earlier interop though it was not specified in the earlier aza spec as far as I can see.
John B.
On Jul 5, 2014, at 12:37 AM, Emily Xu <exu at vmware.com<mailto:exu at vmware.com>> wrote:
Hi John,
Thank you for sending me the latest spec. Hopefully my online signing of the contributor agreement would work so I can post the questions to the list.
Actually the latest spec answered many of my questions. With one thing that needs clarification.
If I have two native apps, let's name them TestApp1 and TestApp2, both need access token to access the same Resource Server (TestRS1). Let's say the scope for TestRS1 is com.testrs1. What will be returned from the AppInfo endpoint? Like something below? Please pay special attention about the name and scope field.
"apps": [
{
"name": "TestApp1",
"type": "native",
"scope": "com.testrs1",
"icon_uri": "http://www.example.com/pic1.png<https://urldefense.proofpoint.com/v1/url?u=http://www.example.com/pic1.png&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=IOcogj9VVYIVG08Q5exet3ZcjD14eQZ74sW8TzsMe2w%3D%0A&s=8d88d0f30400fc8e2ebb6da27f97087042901f488d07933245f94322b9d22477>",
"custom_uri": "testapp1://callback-uri/",
"bundle_id": "nkdf9hfknfih9enfen"
}, {
"name": "TestApp2",
"type": "native",
"scope": "com.testrs1",
"icon_uri": "http://www.example.com/pic2.png<https://urldefense.proofpoint.com/v1/url?u=http://www.example.com/pic2.png&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=IOcogj9VVYIVG08Q5exet3ZcjD14eQZ74sW8TzsMe2w%3D%0A&s=b773acca3bc95051fd4f690cec8fe08f7131a2dcc3b6761c224a77be30b92571>",
"custom_uri": "testapp2://callback-uri/"
"bundle_id": "jdfejfemfefpoemkflen"
}
]
What if a third native app (TestApp3) needs token to access to TestRS1 and TestRS2. What the AppInfo will look like?
{
"name": "TestApp3",
"type": "native",
"scope": "com.testts1, com.testrs2",
"icon_uri": "http://www.example.com/pic3.png<https://urldefense.proofpoint.com/v1/url?u=http://www.example.com/pic3.png&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=IOcogj9VVYIVG08Q5exet3ZcjD14eQZ74sW8TzsMe2w%3D%0A&s=53243901b8e92d8b52aacc98e188eaed013ff064f0df481ed2bfadfc9701efe7>",
"custom_uri": "testapp3://callback-uri/"
"bundle_id": "oejfiejfefjpefefefeifie"
}
Thanks,
Emily
From: John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>
Date: Friday, July 4, 2014 1:40 PM
To: Emily Xu <exu at vmware.com<mailto:exu at vmware.com>>
Cc: Ashish Jain <ashishjain at vmware.com<mailto:ashishjain at vmware.com>>, Paul Madsen <pmadsen at pingidentity.com<mailto:pmadsen at pingidentity.com>>
Subject: Fwd: Openid-specs-native-apps post from exu at vmware.com<mailto:exu at vmware.com> requires approval
You will need to submit a contribution agreement to post to the list.
The one Ashish put in only covers him http://openid.net/wordpress-content/uploads/2013/11/Ashish-Jain-Native-App-WG-Contribution-Agreement.pdf<https://urldefense.proofpoint.com/v1/url?u=http://openid.net/wordpress-content/uploads/2013/11/Ashish-Jain-Native-App-WG-Contribution-Agreement.pdf&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=qIzRydcbKK0gy5xOc475BldnodzIIhQpKNG5XgyrnkI%3D%0A&s=a4265c94e7b15e19e77fcb669a0616168004a0df8017c7086664ad5df059e815>
The link for the contributor agreement is at: http://openid.net/intellectual-property/<https://urldefense.proofpoint.com/v1/url?u=http://openid.net/intellectual-property/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=qIzRydcbKK0gy5xOc475BldnodzIIhQpKNG5XgyrnkI%3D%0A&s=de0d6c9d029cfd5084fdf3b2a3fe2479dd5edcb97e0d8071e140293ba6aeb36f>
Once you do that I can release the post to the list.
I have some comments inline
The current Spec is at: http://openid.bitbucket.org/draft-native-application-agent-core-01.html<https://urldefense.proofpoint.com/v1/url?u=http://openid.bitbucket.org/draft-native-application-agent-core-01.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=qIzRydcbKK0gy5xOc475BldnodzIIhQpKNG5XgyrnkI%3D%0A&s=f297fc78e206a9cbcd353cc5beeab8eca15647cbc3f1843fded8a3fdd2b20c33>
Begin forwarded message:
From: openid-specs-native-apps-owner at lists.openid.net<mailto:openid-specs-native-apps-owner at lists.openid.net>
Subject: Openid-specs-native-apps post from exu at vmware.com<mailto:exu at vmware.com> requires approval
Date: July 4, 2014 at 11:34:44 AM GMT-4
To: openid-specs-native-apps-owner at lists.openid.net<mailto:openid-specs-native-apps-owner at lists.openid.net>
As list administrator, your authorization is requested for the
following mailing list posting:
List: Openid-specs-native-apps at lists.openid.net<mailto:Openid-specs-native-apps at lists.openid.net>
From: exu at vmware.com<mailto:exu at vmware.com>
Subject: native app validation
Reason: Post to moderated list
At your convenience, visit:
http://lists.openid.net/mailman/admindb/openid-specs-native-apps<https://urldefense.proofpoint.com/v1/url?u=http://lists.openid.net/mailman/admindb/openid-specs-native-apps&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=qIzRydcbKK0gy5xOc475BldnodzIIhQpKNG5XgyrnkI%3D%0A&s=c14b20f7d866a1def4b3fe7602557909d895305fde25120675e6f2b6586b88f3>
to approve or deny the request.
From: Emily Xu <exu at vmware.com<mailto:exu at vmware.com>>
Subject: native app validation
Date: July 4, 2014 at 11:34:22 AM GMT-4
To: "openid-specs-native-apps at lists.openid.net<mailto:openid-specs-native-apps at lists.openid.net>" <openid-specs-native-apps at lists.openid.net<mailto:openid-specs-native-apps at lists.openid.net>>
Hello,
I have a few questions regarding native app validation in the NAPPS flow. I'm not sure whether it has been discussed before or not since I cannot find any discussion with relevant topic from the list.
1. Who should validate native app
In existing NAPPS flow, a native app will obtain an access token to access a Resource Server from AS through TA. Whose responsibility it is to verify whether this particular native app can be given an access token?
TA may be able to verify that a request indeed came from a native app. However, TA cannot verify that this native app is authorized to obtain access token to access RS. I assume this validation needs to be done at AS.
I remember in the very first draft of the spec (Summer, last year), customUrl was used by AS to verify the requesting native app. When a native app sends a token request to TA, it passes in scope and customUrl. TA will pass the scope and customUrl to AS. AS then verifies customUrl and make sure the customUrl is pre-registered for an authorized native app.
The info coming back from the app_info endpoint contains the scopes that the app can request. The TA needs to filter the requested scopes.
The app_info endpoint response has optional "bundle_id" and "custom_uri" for identifying the app. In the original spec customurl was in an example but not the normative text. I have added it to the normative text describing the elements returned in the response.
2. customUrl vs. Bundle ID
One potential issue with the customUrl approach is that TA usually could not validate a native app's customUrl. Instead, TA usually knows a requesting native app's bundle ID. So TA could pass a native app's bundle id to AS for AS to validating whether the native app associated with the bundle id is authorized to receive access token.
The TA should probably do both. The custom_uri doesn't validate the request but it prevents the response from going to the wrong app if you can't validate the app signature.
Validating the redirect_uri alone is equivalent to standard OAuth 2 security for public apps. I agree we should try and better that.
3. Multiple native apps to one Resource Server
The original customUrl approach assumes one Resource Server (scope) could have only one native app (customUrl) associated with it. If we decide to ask AS to validate native app using either customUrl or bundle id, then we need to cover the situation where multiple native apps running on the same device may ask access token from AS through TA to access the same RS. In this situation, one RS(scope) at AS side may have multiple native apps registered.
I don't think I get the question. The app info response is an array of app objects. There is nothing I can see that stops multiple apps from asking for the same scope. It is the TA that knows what the client app is and filter the scopes.
This will be good to take to the list once we have the IPR dealt with.
Thanks
John B.
Any thoughts?
Thanks,
Emily
Emily Xu
Identity Management
VMware
From: openid-specs-native-apps-request at lists.openid.net<mailto:openid-specs-native-apps-request at lists.openid.net>
Subject: confirm 076f42cf7666c4fb6036fcd427d6cad59b11b641
Date: July 4, 2014 at 11:34:44 AM GMT-4
If you reply to this message, keeping the Subject: header intact,
Mailman will discard the held message. Do this if the message is
spam. If you reply to this message and include an Approved: header
with the list password in it, the message will be approved for posting
to the list. The Approved: header can also appear in the first line
of the body of the reply.
_______________________________________________
Openid-specs-native-apps mailing list
Openid-specs-native-apps at lists.openid.net<mailto:Openid-specs-native-apps at lists.openid.net>http://lists.openid.net/mailman/listinfo/openid-specs-native-apps<https://urldefense.proofpoint.com/v1/url?u=http://lists.openid.net/mailman/listinfo/openid-specs-native-apps&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=UEqMEvaZfh1vF8kq3ltquHMhlT53kIiYvkNi0KUT6EU%3D%0A&s=0d6f04210506a8e8362d320363586686d30197e6d671c70c8a21a291cd47f9cf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20140708/4f998a62/attachment-0001.html>
More information about the Openid-specs-native-apps
mailing list