3:46 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev