2:27 a.m.
On 01/04/16 02:21, Anthony Fryer wrote:
Hi,
Up until recently I automatically selected to use implicit grant flow
from SPAs, but lately I’ve been re-assessing this since the keycloak
javascript adapter provides standard flow out of the box and makes
that a viable option. I also note that the keycloak admin console is
a HTML5/javascript/angular js app that uses the keycloak js adapter
and uses the standard flow. As a side note I find the client defaults
interesting in that Implicit flow is disabled, but direct access
grants are enabled (I’m coming from a mitreid connect implementation
where direct access grants where disabled by default and implicit flow
was enabled, so just wonder what the thinking is behind this since
direct access grants are discouraged).
Direct grants is enabled mostly for backwards compatibility and for
having slightly easier some admin tasks. For example because direct
grant is enabled, you have possibility to invoke admin REST endpoints
once you start Keycloak, which is widely used in tests. Without direct
grants enabled, you would first need to manually go to admin console and
enable it for admin console client, but that's not easily just with
admin REST endpoints (outside admin console UI) if it is disabled - in
other words it's classic chicken-egg problem.
The direct grants is discouraged mainly because it requires users to
enter their password in your app instead of Keycloak server. However:
- If your app is web-based and doesn't require direct grants, you just
won't ask users to enter their password into your app
- If your app is not web-based and requires direct grants, you would
still need to enable direct grant and ask people to enter their password
into your application. If they don't trust it, they just reject to enter
password to your app.
So from security and end-users perspective, there is not much difference
between the case when direct access grant is enabled or disabled by
default IMO.
I’m really wondering why are you pushing standard flow from the
keycloak javascript adapter instead of implicit? What are the
benefits that make standard flow better in this case? One thing I
have seen mentioned is refresh tokens obtained in standard flow make
it easy to get a new access token, but I thought you could get refresh
tokens from the implicit flow anyway, and even if not, if a user logs
in with “remember me”, then getting a new access token doesn’t require
re-entering credentials by the user. I want to make sure that when
implementing keycloak in our SPA we choose the best flow and want to
know if there’s some reason standard flow is best.
Yes, the refreshing tokens is not allowed in implicit flow per OIDC
specification. Also there are accessToken and idToken sent in the URI
fragment in implicit flow, which can in theory have some security
implications.
So with implicit flow, you have to redirect to login screen (as you
mentioned above) instead of just simply refreshing tokens. Redirecting
to login screen is usually worse for performance-wise than refreshing
tokens and also requires some change in logic of your javascript app,
but it's doable (For example you can implement callback
keycloak.onTokenExpired or you can always manually check the expiration
on accessToken before sending refresh request to 3rd party service).
Logic for refreshing token in javascript app is quite simple, you just
need to wrap the REST call with keycloak.update to ensure the
accessToken is automatically refreshed by adapter in case that it's
expired (or going to be expired).
Marek
Regards,
Description: Description:
C:\Users\jayt\Desktop\tonyjay_sig_files\virginaustralia.gif
*Anthony Fryer*| Solution Architect & Designer
Mb: 0438 781 745
Email: anthony.fryer(a)virginaustralia.com
<mailto:anthony.fryer@virginaustralia.com>
Virgin Australia group of airlines including Virgin Australia,
V Australia, Pacific Blue and Polynesian Blue
Please consider the environment before printing this email.
The content of this e-mail, including any attachments, is a
confidential communication between Virgin Australia Airlines Pty Ltd
(Virgin Australia) or its related entities (or the sender if this
email is a private communication) and the intended addressee and is
for the sole use of that intended addressee. If you are not the
intended addressee, any use, interference with, disclosure or copying
of this material is unauthorized and prohibited. If you have received
this e-mail in error please contact the sender immediately and then
delete the message and any attachment(s). There is no warranty that
this email is error, virus or defect free. This email is also subject
to copyright. No part of it should be reproduced, adapted or
communicated without the written consent of the copyright owner. If
this is a private communication it does not represent the views of
Virgin Australia or its related entities. Please be aware that the
contents of any emails sent to or from Virgin Australia or its related
entities may be periodically monitored and reviewed. Virgin Australia
and its related entities respect your privacy. Our privacy policy can
be accessed from our website: www.virginaustralia.com
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
