I would like to use a self-hosted OpenID Connect (OIDC) server in a combination with JWT as an authorization token (access token in OIDC terms). JWT would be used to protect REST services while the UI are a mix of classical and single-page applications (Angular). This way, the REST layer would be able to do the authorization based on a stateless JWT token so no extra DB connections are necessary, as described here:
https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/
For a single page app, OIDC Implicit Flow is appropriate. However, I see a security problem when Implicit Flow is used in combination with stateless JWT tokens: Tokens are delivered as a fragment part in the URL which means there is no way to remove them (they are easily available in the browser history) nor invalidate them (they are stateless) -> no logout possible.
I see 2 options to mitigate this:
The third option would be to give up stateless JWT tokens and use simple bearer tokens with DB checks.
Do I miss something? What would you choose?
Stateless authentication uses tokens, most often a JSON Web Token (JWT), that contain the user and client information. The server only has to match the token key and cryptographic signature with the information on file, meaning it can do far less work in looking up identity provider (IdP) information.
OpenID Connect is built on the OAuth 2.0 protocol and uses an additional JSON Web Token (JWT), called an ID token, to standardize areas that OAuth 2.0 leaves up to choice, such as scopes and endpoint discovery.
Token-based authentication enables users to obtain a token that allows them to access a service and/or fetch a specific resource without using their username and password to authenticate every request.
AM OAuth 2.0-related services are stateless unless otherwise indicated; they do not hold any token information local to the AM instances. Instead, they either store the OAuth 2.0/OpenID Connect tokens in the CTS token store, or present them to the client.
one may argue about the risk of fragments ending up in browser history, but "simple" opaque bearer tokens would be subject to the same limitations that you describe for JWT tokens
using a code flow with AJAX is certainly not prevented by the OpenID Connect specification so you could use just that; the implicit flow is only a recommendation for in-browser clients as it optimizes the number of round-trips to get a token to the user agent
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With