[keycloak-user] always-refresh-token and admin rest api

[Marek Posolda]

Adding list back. Make sure to click on "Reply all" as you have much 
bigger chance that someone will reply you :-)

On 20.4.2015 15:11, Benjamin Hansmann [alphaApps] wrote:
> On Fri, 2015-04-17 at 17:48 +0200, Marek Posolda wrote:
>> On 17.4.2015 13:30, Benjamin Hansmann [alphaApps] wrote:
>>> Greetings. Following up my post from yesterday I have more specific
>>> questions.
>>>
>>> I plan to use keycloak with my REST service for mobile apps as follows:
>>>
>>> Option A:
>>> 1 A user sends a REST registration request to my webapp and the webapp
>>> adapts the request to the local keycloak admin rest api.
>>> 2 When the user is created he can then authenticate to keycloak via the
>>> direct access grant rest api and receives an access token.
>>> 3 The issued access token should be valid for only one request, thus I
>>> specified the option "always-refresh-token": true in my webapp's
>>> keycloak.json file.
>>>
>>> Option B:
>>> 1 Mobile app forms the HTTP POST request to the user registration page.
>>> 2 and 3 as in Option A
>>>
>>> Option C:
>>> 1 Use a user federation provider and create users in my webapp's
>>> datasource.
>>> 2 and 3 as in Option A
>>>
>>> Question regarding all options:
>>> How is the "always-refresh-token" option supposed to work? I supplied
>>> the option as stated above but I am still able to reuse access tokens
>>> that were issued from the direct access grant service. Another question
>>> is how this token refreshing should be implemented on the client side.
>>> Do I have to invoke on the direct access grant api to obtain a new token
>>> for every request or can the issued "refresh_token" be used on
>>> subsequent requests and a new refresh token is somehow included in the
>>> response of my service?
>> This option is used for servlet adapters. Each HTTP request to the
>> servlet frontend application (For example "customer-portal" or
>> "product-portal" from our demo) will perform sending back-channel
>> request to the Keycloak auth-server and will refresh the token. You can
>> try change our demo and add the option for example to the
>> customer-portal keycloak.json:
>> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/webapp/WEB-INF/keycloak.json
>> and then check in the application that accessToken is different in each
>> request:
>> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L56
>> .
>>
>> This option has no effect for bearer-only applications as those are
>> authenticated by accessToken sent from different application and they
>> don't support any token refreshing at all. It also doesn't have any
>> effect for direct grant API (we don't have any adapter for direct grant
>> API. People are expected to invoke the HTTP request to retrieve
>> accessToken from auth-server with direct grant API by themselves as
>> shown in the documentation or in the admin-access-app example)
>>
>> Marek
> Thanks Marek. With tcpdump I could see that access tokens are refreshed
> on each request when logging into my realm through the keycloak web
> front-end. These mechanisms seem to be based on cookies so there are not
> feasible for my application.
>
> As always-refresh-token doesn't work with the direct grant api I will do
> it as follows:
> - Mobile application will login with saved password
> through /auth/realms/<my_realm>/tokens/grants/access
> - When token expired (after 3 minutes) on subsequent request, mobile
> application will refresh token
> through /auth/realms/<my_realm>/tokens/refresh
> - If session (and issued refresh_token) expired due to inactivity (after
> 10 minutes) automatically login again
> - Set revocation policy on sensible rest requests to something >3
> minutes
> - Implement REST adapter to the keycloak admin api to let users register
> and manage their profiles
>
> In this scenario I do not need the web-frontend for users,
> e.g. /auth/realms/<my_realm>/protocol/openid-connect, /auth/realms/<my_realm>/account, /auth/admin/<my_realm>/console, so I deleted the applications security-admin-console, account etc. from my realm. Is it possible to completely disable all web-frontends to this realm/application as some urls remain accessible? The JSON realm description from a GET /auth/realms/<my_realm> also still lists token-service, account-service and admin-api.
>
> I also set bearer-only to true in my adapter config to disable the 302
> redirects to the login web-frontend and instead return 401 unauthorized,
> although my realm is configured as public to provide the direct access
> grant api.
>
> I also do not want to expose the admin master console and other web
> services related to my master realm externally. Is it possible to let
> these listen only on the local loopback device, e.g. a configuration
> option like the socket-binding of wildfly?
Keycloak is just a WAR deployed similarly like any other war on WildFly 
or EAP6. So when starting Keycloak on Wildfly or EAP6, you can just use 
the option like:
./standalone.sh -b localhost

and it should be bound just to the localhost. Is it sufficient for you?
>
> I really like keycloak, though I think it is currently more dedicated to
> browser applications than mobile ones. Are there any plans for the
> future to adapt to special mobile client needs?
I think there are plans and AFAIK we rely on the help from the aerogear 
team to help with the mobile adapters. I don't know the details and 
timeframes, but maybe someone else on this list has more info :-)

Marek
>
> Best regards,
> Benjamin
>
>
>>> Question regarding option C:
>>> When creating users in my own database which serves as a federation
>>> provider I loose some keycloak functionality like Email verification and
>>> so on, right?
>>>
>>> I am also not sure which option to use. What would you suggest.
>>>
>>> Feature request:
>>> It would be great to have a keycloak REST API for registration and user
>>> self-service in order to fulfill the demands of mobile applications.
>>>
>>> Best regards,
>>> Benjamin