Hi folks, I have some questions about using the access token to log in to web applications which are using the “Authorization Code Flow”.
A brief overview of our setup:
We’re running a couple of open source web applications (Moodle, Hedgedoc, RocketChat, …) which uses Keycloak as IdP. All of theses web applications are using the “Authorization Code Flow” (explicit flow) for authentication. Unfortunately, this can’t be changed. Now, when a user wants to login to e.g. Hedgedoc and clicks the login button, the user will be redirected to Keycloak which presents a common login form with username and password. When the authentication was successful, there is a redirect back to the application (Hedgedoc in this example) with the authorization code, which is utilized by the application to (internally) retrieve an access token, to authorize the user and then to return a session cookie.
What we want to achieve:
Currently we’re developing a mobile app that should open all of these web applications in a web view. Here, however, the user should only have to log in to the mobile app once, right at the start. When the user wants to open any of the web applications (in a web view) in the mobile app it should work without having to log in again. For this purpose, we are also developing a middleware service which exposes a JSON API where the mobile app can request the individual session cookie for each web application. This session cookie is sent, per web application, with each request, so that the user is already authenticated and a login is not required.
For the mobile app login we use the grant_type=password (implicit flow) which returns an access token, refresh token and an identity token. This works as expected, however our problem is how to use this access token for login with the “Authorization Code Flow” of each web application? I can reproduce the authorization flow per web application in the middleware, but this would require to store the user credentials (username/password) somewhere in the mobile app to request the session cookie from the middleware service. But that’s not what we want! Therefore, is it possible to pass the access token as a parameter to the authorization_endpoint so that no login form is shown up? Do you know other options?
Unfortunately, the web applications themselves are unable to deal with the access token and cannot be updated.
Implicit and ROPC grant types are both deprecated and should not (Implicit) [1] or must not (ROPC) [2] be used, both grants will be omitted in OAuth 2.1 spec [3]
Just to explain: that’s not correct, grant_type=password is the ROPC grant, Implicit flow does not have a grant_type, as the token endpoint is not called, because the token is contained in the redirect back from the auth server (instead of the authz-code when using the auth-code-grant).
But as both grants are deprecated (see above), just don’t use them!
This is absolutely correct and also our problem. The IdP cookie expires after some time, which unfortunately makes a " longer usage" of the cookie impossible. For security reasons, this is a good thing, but a user of our mobile app should not have to log in again if they want to start e.g. the Moodle browser view, for example, three days after logging in to the mobile app.
Is there any way to achieve the behavior of a “transparent login in the background” without asking the user to enter his username and password again?
If you follow the standard, you avoid asking for a password when you have SSO or if your app uses refresh tokens. With refresh tokens, the app can refresh the tokens in the background.
Lastly, offering only the username and password authentication mechanism is like being in the old days . You can use Passkeys (WebAuthn), enabling signing in with just your fingerprint, face scan, or screen lock. Here, you have a workshop that not only showcases how to use Passkeys but also demonstrates the transition from a password-based to a passwordless experience using WebAuthn Conditional UI or Passkeys Autofill [1]
, plus more in detail:
. You can use Passkeys (WebAuthn), enabling signing in with just your fingerprint, face scan, or screen lock. Here, you have a workshop that not only showcases how to use Passkeys but also demonstrates the transition from a password-based to a passwordless experience using WebAuthn Conditional UI or Passkeys Autofill [1]