[keycloak-user] Recommendations for protecting REST service with bearer token and basic auth

Bill Burke bburke at redhat.com
Fri Nov 21 11:09:08 EST 2014



On 11/21/2014 10:37 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-user at lists.jboss.org
>> Sent: Friday, 21 November, 2014 2:47:39 PM
>> Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth
>>
>> Why do you need to do something that complicated?  You could have
>> per-app/oauth-client token policies.  The token policy could have a
>> refresh token expiration policy of never.  Then everything just hooks
>> into existing screens and architecture.
>
> That'd be good as well, but it would still expire when user session expires. You need to have an option to let a client create tokens that are not linked to the user session. Also, for oauth clients the grant page should say that the app is requesting offline access. Having an offline toggle and per-app expiration would work at least initially, but I think in the future we'll have to support scope query param.
>

I don't think we ever want to separate the token from the user session. 
  User and client session contains information about:

* how the user logged in (auth method)
* IP address
* When they logged in.

All information you'll want to display to the user and admin.

Instead, maybe a specific REST api for creating long-lived user 
sessions/refresh tokens?  A client would make an authenticated request 
to this admin api, provide the refresh token it obtain through normal 
mechanisms, server would check to make sure the client is allowed to 
"upgrade" the refresh token, create a new UserSession/ClientSession, 
create a new refresh token, send back the refresh token.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


More information about the keycloak-user mailing list