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