You need to decide if you want the front-end to hold tokens or not. If
front-end holds tokens you can do Auth code flow securely with pkce and
public clients. That means your front-end should move secure and you should
really only store tokens temporarily in the window state rather than in
html5 storage. This is perfectly acceptable in most cases.
The alternative is to have a backend for your front-end that deals with
obtaining tokens. The front-end uses a httponly cookie to be authenticated
against the backend, but never has access to the token directly. This has
the limitation that front-end and backend has to be hosted on same domain
and if you need to call external services it needs to be proxies through
the backend. It is harder to do though.
An hybrid approach like you mention doesn't make any sense to me.
On Tue, 27 Aug 2019, 11:18 bob sheknowdas, <bob.skd(a)googlemail.com> wrote:
Hi,
I have a setup and a usecase that seems to be quite unique (according to my
google search effords).
I use a frontend consisting of pure java script (microservice 1).
Behind that runs a backend created with java spring boot (microservice 2).
To authenticate users I want to switch from the implict flow to the
auth-code-flow for additional security.
However, this additional security can not be achieved using a pure java
script client...
So I had the following idea:
Integrating the backend into the auth-code-flow of the frontend.
I was planing to let the request to the authorization-endpoint be handled
by the frontend alone, but than proxy the request to the token endpoint
through the backend (where the client secret is injected).
Does the keycloak spring-boot-adapter provide any useful functionality for
this usecase?
Is this a good idea in general?
I am thankful for any help or comment provided :)
Best
Bob
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user