11:46 a.m.
Cool. I‘ll think about it a little and put together a design proposal.
+1 for deprecating implicit flow.
Am 19.07.2019 um 10:46 schrieb Stian Thorgersen
<sthorger@redhat.com<mailto:sthorger@redhat.com>>:
Hi Gregor,
Sorry for not replying to this earlier, but I have been away on PTO (and about to go away
again, so may not reply to any replies from you in a timely manner).
I agree that we can do some work here on improving the security around SPAs and should
consider two different solutions:
1. SPA does not have access to tokens (app server is a credential client) - either it only
invokes a single service hosted on same domain, or it invokes external services through
the service hosting it (Apps Served from a Dynamic Application Server)
2. SPA has access to tokens directly (browser app is a public client)
1 is at least somewhat more secure, but is a lot more tricky to do.
It would be great to start a design proposal around both scenarios as a next step before
we make any decisions on how to proceed. A few points from me for now though:
* Should be possible to mark a client as a browser-based client - perhaps we need to
introduce the concept of client types
* Should be possible to prevent sending refresh tokens to specific clients - I have
thought about introducing client types before, where a browser client type would follow
best practices for a browser and if someone needs a different type they would use a
generic client that would enable more configuration options
* OIDC client registration already has the concept of application_type
(https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata), but
it's very limited to web / native, but I guess that can be extended on
* Should be possible to obtain new access tokens without reloading SPA - best option here
is probably iframe approach
* Redirect URI for browser based apps should not allow wildcard at all (*,
http://address.com/*), but only support a direct mapping (not sure about query params and
hash, but probably not allowing those either and having some different way to recover hash
part for SPA)
Maybe we should consider deprecating Implicit flow
We should probably also consider adding some write-up around SPAs to Keycloak docs.
On Mon, 1 Jul 2019 at 17:48, Gregor Tudan
<Gregor.Tudan@cofinpro.de<mailto:Gregor.Tudan@cofinpro.de>> wrote:
Hi everyone,
After reading https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps on how to
secure SPAs with OAuth I would like to implement the measures outlined there. I know it’s
still a draft, but the arguments stated there make a lot of sense - including that doing
OAuth in the browser only should only be considered if session based auth or some kind of
backend (like gatekeeper) is not an option.
Here’s what the draft suggests:
* use public clients only as one cannot keep secrets private (easy)
* Use the Code-Flow with PKCE to secure the token exchange (possible with the
JS-Adapter from v7)
* Don’t expose the refresh token to the client (I don’t think that’s possible with the
code flow today).
* If this is not possible return a new refresh token on every refresh invalidating
the old one.
* Don’t use Implicit flow - it safes roundtrips but is vulnerable to numerous attacks
(easy - see above)
So while a lot has been done, there still seems to be the issue about the refresh
tokens.
First off, I’m not sure how to obtain an access token only during the Access Token Request
- while the spec states that the refresh token is optional, there is no parameter defined
to communicate this kind of behavior to the auth server. Can this be configured in the
client?
Let’s say I managed to obtain an access token. The second issue is: how can I refresh it
without a refresh token? It was suggested to use the session with the Auth-Server for
this, but with the current Javascript-Adapter this would mean doing a full reload every
two minutes and having to reboot the SPA. This is not practical.
The other option would be to do this in an iframe with promt=none. A similar approach was
supposed and implemented in https://issues.jboss.org/browse/KEYCLOAK-6795 (Silent
Authentication in Iframe for Implicit Flow), but abandoned due to the usage of the
implicit flow. Stian suggested to use the code flow with PKCE instead, but this would mean
picking having to do an extra call inside the iframe.
I’m happy to work on something similar for PKCE, but before starting I would like to make
sure that this kind of feature makes sense and has a chance to get accepted.
- Gregor
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev