Oauth Flow for Non Browser App

[Navin Kaushik]

Hi All,

In case of B2B space, where desktop application belongs to someone else but that desktop application consuming our REST APIs, is it fine to expose resource owner credential flow ?

Also, I hope it's ok that JWT will be in hostile environment i.e user can see what's inside in access token ofcourse they can't modify it.

Summary, two things:

1. Is it fine to expose resource owner credential flow for public non browser clients ?

2. Is it fine to give JWT to public non browser clients ?

-Regards,

Navin

[Tony Harris]

Navin

For me two approaches work here.  First using client_credentials grant, i.e. client_id, client_secret to obtain an access token is a well trodden path.  if you have multiple consumers of your api then a separate client_id and secret per consumer will give you some control and auditing over each request.

You could also look at offline_access tokens, these can be generated for a real user against a single client , rather than for a service account user as above.  You can revoke those tokens as required and each consumer can be issued one that is unique to them with the allowed scopes and roles as desired.

As with any authentication is only as strong as the person holding the keys.  In terms of the password grant its the password, client_credentilas its the client_id and client_secret and with the offline token its the token itself.  All methods result in a JWT being issued to a third party client and its standard practice in consuming API's

--
You received this message because you are subscribed to the Google Groups "Keycloak User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/44cc83e8-b636-42f7-b224-42b5e075e3c7n%40googlegroups.com.

[Navin Kaushik]

Thanks for the response.

Since, there can be 100,000 end user clients, so client id & secret for each doesn't makes sense.  I am thinking of what you mentioned in middle which is getting offline access token for real user against single client id.  Client would be public, so client id is sufficient and authorization code flow with PKCE would be used. 

[Phil Fleischer]

We use the direct grant / resource owner token flows for some select applications.  

The main challenge we had was making sure clients handled any required action responses and in some cases we even customized the token endpoint to add additional error information (mostly in headers to not diverge from the oauth spec).  In my opinion it mainly just complicates the authorization flows that you have to support all the same interactions that a web flow supports (update profile, password expiration, etc.)

Another thing we did was made sure the was not full scope and only grant roles that were specific to the resources that we were exposing.

On the sensitivity of the tokens, even in browser flow you can easily pull the access token network auth headers, so I don’t think it’s relevant to the security of the direct vs. code browser flows.  I’m not an authority, but from experience our attackers 

-- Phil

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/976f5630-26a9-46ae-bc1b-d85ec4321fban%40googlegroups.com.