Salut,
tu dois pouvoir faire au authorization end point un responce_type=id_token+token pour obtenir à la fois un id_token pour valider l'authentification coté client et un access_token à faire suivre en header authorization bearer à tes API (mais tu peux aussi ne demander que le token puis faire un appel à ton back qui lui fera un appel au end point user info pour obtenir l'identité de ton utilisateur, ou ne faire que de l'id_token)
Le problème dans ce scenario étant de rafraichir les jetons sans re passer par la case authorisation.
Une autre possibilité est de faire du response_type=code avec une url de retour interprété coté back (qui pourra donc garder les jetons) avec en retour par exemple le token qui pourra alors être envoyé au api sous forme d'un header. Quand le token sera expiré, il suffira donc de rappeler l'url qui renouvelle ce dernier grace au refresh_token.
[^] # Re: keycloak ?
Posté par Mathieu CLAUDEL (site web personnel) . En réponse au journal Glewlwyd 2.0, serveur SSO, est maintenant en RC1. Évalué à 1.
Salut,
tu dois pouvoir faire au authorization end point un responce_type=id_token+token pour obtenir à la fois un id_token pour valider l'authentification coté client et un access_token à faire suivre en header authorization bearer à tes API (mais tu peux aussi ne demander que le token puis faire un appel à ton back qui lui fera un appel au end point user info pour obtenir l'identité de ton utilisateur, ou ne faire que de l'id_token)
Le problème dans ce scenario étant de rafraichir les jetons sans re passer par la case authorisation.
Une autre possibilité est de faire du response_type=code avec une url de retour interprété coté back (qui pourra donc garder les jetons) avec en retour par exemple le token qui pourra alors être envoyé au api sous forme d'un header. Quand le token sera expiré, il suffira donc de rappeler l'url qui renouvelle ce dernier grace au refresh_token.