Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth
On 11/21/2014 10:37 AM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: keycloak-user(a)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