5:34 a.m.
Hello. We are evaluating Keycloak/OIDC as an authentication solution. Apart from SSO and
Multi-Factor-Authentication, one use-case we have is a carousel of login-forms in our
SPA:
| User A | <=> | User B | <=> | User C |
| Passwd | <=> | Passwd | <=> | Passwd |
We want our users to quickly switch their sessions at a terminal (running our SPA-client).
The main challenge here is to integrate the login form in the parent instance instead of
redirecting to a new website. Our findings are that this is possible with the
“Password"-flow. But since the recommended flow for SPAs is the “Implicit” one (for
obvious security reasons), we would prefer that over Password, if the described carousel
is possible with it.
For the Implicit flow there is the possibility to do a silent refresh. It utilizes an
invisible iframe for the redirect which provides a new token. Is it possible to do the
same trick for the initial log-in? I don’t see how the refresh is different from the
login. The way I get is is that for the refresh you inject the old token in the iframe and
it delivers the parent app a new one. For the initial login, why would it not work to
provide the iframe with credentials instead and trigger the redirect the same way as the
refresh?
Is there any other workaround to implement Implicit? If we have to go with the password
flow, what are the implications for our security, considering we utilise HTTPS and
XSS-/CSRF-measures? The main problem would be old or infected browsers, no? This website
here says to use Password flow only for "highly trusted clients”:
https://auth0.com/docs/api-auth/which-oauth-flow-to-use
<https://auth0.com/docs/api-auth/which-oauth-flow-to-use> And we will be the only
ones writing client code, so is Password A-OK for us?
Thank you and Regards, Phil
- - - - - - - - - - - - -
ConceptPeople consulting gmbh
Philip Lysenko
Lead-Developer
ConceptPeople consulting gmbh
Yokohamastraße 2
20457 Hamburg
Tel: 040 - 605 33 83 53
Fax: 040 - 605 33 83 99
www.conceptpeople.de
Geschäftsführer:
Bjarne Jansen, Andreas Rother
Steuer-Nr: 46/712/02908
UID-NR: DE219814648
Registergericht:
Hamburg, HRB 82938
4:59 a.m.
Hi Philip,
Is it correct that you're presenting the user with native login forms (instead of
redirecting to Keycloak), but would like to avoid using direct grant flow at all costs?
I think you could try to emulate implicit flow-based login in an iframe. For that:
1. initiate login process with Keycloak using auth endpoint;
2. Keycloak will respond with a login form, you'll need to parse its
"action" attribute;
3. submit the form, retrieve access token from the "code" parameter from the
URL.
To watch in detail how the flow works, create a test client (just some dummy app), enable
Implicit flow and analyze HTTP conversation in your browser's network console.
Good luck!
Dmitry Telegin
CTO, Acutus s.r.o.
Keycloak Consulting and Training
Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
+42 (022) 888-30-71
E-mail: info(a)acutus.pro
On Thu, 2018-08-02 at 12:34 +0200, Philip Lysenko wrote:
Hello. We are evaluating Keycloak/OIDC as an authentication solution.
Apart from SSO and Multi-Factor-Authentication, one use-case we have is a carousel of
login-forms in our SPA:
> User A | <=> | User B | <=> | User C |
> Passwd | <=> | Passwd | <=> | Passwd |
We want our users to quickly switch their sessions at a terminal (running our
SPA-client). The main challenge here is to integrate the login form in the parent instance
instead of redirecting to a new website. Our findings are that this is possible with the
“Password"-flow. But since the recommended flow for SPAs is the “Implicit” one (for
obvious security reasons), we would prefer that over Password, if the described carousel
is possible with it.
For the Implicit flow there is the possibility to do a silent refresh. It utilizes an
invisible iframe for the redirect which provides a new token. Is it possible to do the
same trick for the initial log-in? I don’t see how the refresh is different from the
login. The way I get is is that for the refresh you inject the old token in the iframe and
it delivers the parent app a new one. For the initial login, why would it not work to
provide the iframe with credentials instead and trigger the redirect the same way as the
refresh?
Is there any other workaround to implement Implicit? If we have to go with the password
flow, what are the implications for our security, considering we utilise HTTPS and
XSS-/CSRF-measures? The main problem would be old or infected browsers, no? This website
here says to use Password flow only for "highly trusted clients”:
https://auth0.com/docs/api-auth/which-oauth-flow-to-use
<https://auth0.com/docs/api-auth/which-oauth-flow-to-use> And we will be the only
ones writing client code, so is Password A-OK for us?
Thank you and Regards, Phil
- - - - - - - - - - - - -
ConceptPeople consulting gmbh
Philip Lysenko
Lead-Developer
ConceptPeople consulting gmbh
Yokohamastraße 2
20457 Hamburg
Tel: 040 - 605 33 83 53
Fax: 040 - 605 33 83 99
www.conceptpeople.de
Geschäftsführer:
Bjarne Jansen, Andreas Rother
Steuer-Nr: 46/712/02908
UID-NR: DE219814648
Registergericht:
Hamburg, HRB 82938
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
2348
days inactive
2352
days old
1 comments
2 participants
participants (2)
-
Dmitry Telegin -
Philip Lysenko