OpenID Connect is built on OAuth, not UMA. There's no definition for doing OpenID Connect on top of UMA, and I would argue that it doesn't really make sense: OpenID Connect is an identity protocol and the whole point is to delegate access to the current user's identity API, which is what OAuth does. UMA would give you access to some other party's identity API, which doesn't tell you who's logged in right now. While they're often used together, they solve very different use cases. Think of it like having a hammer, a saw, and a screwdriver in the toolbox. They're all there for different reasons but you can use them all to build your cabinet or whatever.

Hopefully this helps untangle some things. 

 -- Justin

On 6/8/2017 7:29 AM, Pedro Igor Silva wrote:

OK. Thanks, Justin.

OAuth2 spec does cover public clients, which are usually related with usage of a implicit grant. But in UMA 2.0 it seems we have now a specific grant type, which flow and examples are really specific to confidential clients. And more important, UMA grant type does not seem to support redirection which is something essential if you want to support public clients. Based on OAuth2 specs, public clients are able to obtain tokens from the authorization endpoint (not token endpoint) based on their client_id and redirection_uri when using implicit grant.

Like I previously mentioned, to avoid using implicit grant we would just support a bearer token when using UMA grant type (and token endpoint). Some of our use cases are related with public clients authenticating with Keycloak based on OpenID Connect where an ID token and AT is already available to them. 

One last question, this one about UMA compliance. We would like to include Keycloak in the list of UMA implementations after reviewing what we have in order to conform with latest version of the spec. Is there a TCK or some other process we need to follow to achieve this ?

On Wed, Jun 7, 2017 at 10:27 PM, Justin Richer <jricher@mit.edu> wrote:

There’s nothing in the spec about public clients because it’s all covered in OAuth 2 (RFC6749 specifically).

 — Justin

On Jun 7, 2017, at 12:57 PM, Pedro Igor Silva <psilva@redhat.com> wrote:

On Wed, Jun 7, 2017 at 12:21 PM, Justin Richer <jricher@mit.edu> wrote:

That is not correct. You can have a public client in UMA 2.0, and in fact you inherit all of the various OAuth client types and authentication methods since you’re talking directly to the token endpoint to get the RPT instead of a special thing. But remember, you needed to talk to the AS to get an AAT previously anyway, so you’ve already needed to have those bits in place in your client.

Really, do whatever you’d have done previously to get the AAT (which required an OAuth transaction with the token endpoint) and use it with the token endpoint to get the RPT now. So you always needed a client ID before anyway, that’s not new, and now you can use your secret or key or nothing just like you used to, but in a different part of the process.

Yes, use the AAT with the token endpoint is what I have in mind. If that is fine and still in sync with the spec for me is fine. But, is there anything in spec about public clients ?

 

Is it recommended that you use a confidential client where possible? Definitely, as the increased security is well worth the minimal effort that’s usually required. There are a lot of cases where it doesn’t make sense though, like a browser or native app that’s not using dynamic registration. In any event, this is all now directly inherited from OAuth instead of being reinvented from OAuth, as it was in 1.0.

That is exactly one of the use cases we need to support. 

 

 

 — Justin

On Jun 7, 2017, at 10:58 AM, Pedro Igor Silva <psilva@redhat.com> wrote:

Hello,

It has been a long time since my last message to this group. Since then we have implemented quite a few things in Keycloak [1] in order to support fine-grained permissions and UMA 1.0.

We are not full compliant yet and some pieces are still missing in our implementation. But we already have the backbone to start implementing now the rest of the spec.

One of my main tasks is now update our implementation to UMA 2.0 and it seems that one of the main changes is related with the removal of AAT in favor of a specific grant type for UMA.

In UMA 1.0 clients were not really forced to authenticate using client credentials when interacting with the RPT endpoint (Authorization API), but just use a AAT as a bearer token. Now, with UMA 2.0, it seems that clients really need to be confidential and use its credentials (e.g.: id/secret or jwt) to authenticate with the token endpoint when using UMA Grant.

Is that correct ?

[1] https://keycloak.gitbooks.io/documentation/authorization_services/index.html

Thanks.
Pedro Igor

_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma