Welcome. Ask away! Unless otherwise specified we assume you're using the latest 6.x version of Spring Security
More generally, it doesn't capture what SSO allows you to customise and extend at a single point, but which SS perhaps doesn't. Going by what I'm using, that's the aforementioned
TokenStore, but also the TokenGranter, RequestFactory, RequestValidator, and ConsumerTokenServices.
I've got lots of bits put together so I could build a page to view and revoke the access that you've granted.
@OrangeDog Spring Security 5 implementation is more strict to what the OAuth 2.0 and OpenID Connect specs define. Regarding opaque tokens, the OAuth 2.0 standard only defines an introspection endpoint (https://tools.ietf.org/html/rfc7662) to validate such a token. Additionally, the OpenID Connect specification defines a user info endpoint (https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) to ask for more user details using an access token. All other means like "arbitrary string that can be looked up via any method, in particular, a JDBC, Redis or in-memory database shared with the auth server" are not according to the standard and bear security risks. Especially the database of the auth server should be used exclusively by the auth server and must not be shared with any other party!
In case you want to persist tokens in your OAuth2/OIDC client then you have to implement the interface "OAuth2AuthorizedClientRepository" yourself to store data it into a database (e.g. Redis). The default implementation just stores the data in the HTTP session.
In case you want to persist tokens in your OAuth2/OIDC client then you have to implement the interface "OAuth2AuthorizedClientRepository" yourself to store data it into a database (e.g. Redis). The default implementation just stores the data in the HTTP session.
As I feared. There are no specific standards for other opaque token implementations, because they don't require different systems to talk to each other, so there's no need to define any public communication protocols. It is very common that the auth server and the resource server are the same party, even implemented in the same process.
The core OAuth 2.0 spec says you can implement bearer and authorisation tokens however you please.
I'm not maintaining a client, I'm maintaining a web service that allows other developers to use its api.
And in a minimal deployment, they're the same process.
Just like every web service that both has its own accounts and offers api access
But Spring Security seems to be taking a very narrow view of what OAuth is and completely cutting out this use case, that was amply served by Spring Security OAuth
That is what Spring Security OAuth just provided with its "EnableAuthorizationServer"/"EnableResourceServer" annotations. With these, you could implement an AuthServer also providing a user info endpoint (which acted like a resource server). You won't find this with any other OAuth/OIDC provider like Keycloak, Okta etc.
OAuth is not just an authentication/ID system.
Hoping to get a little help about configuring multiple OAuth2 IDPs in our Spring Boot API Gateway. We are currently using Zuul but are also PoCing Spring Cloud Gateway so either is relevant.
We'd like to use tenant URLs for our Federated users each using a different IDP for authentication but ultimately have them go through the same gateway. Is there a way to switch OAuth configurations based on the tenant of the URL? A couple considerations; 1) we do not want a login selector screen - we'd like to manage that through different security configurations, 2) the redirect URL should contain the tenanted URL. Is this possible? Easy/Hard?
But for Facebook, Google or Github this just the same. They also separate the OAuth2 token retrieval process from using their APIs with such a token.
Spring Security OAuth has been a bit insecure implementation that is why Spring switched to use Nimbus SDK to do the OAuth2 stuff instead of implementing it themselves.
@OrangeDog If you are looking for a multi-tenant IDP feature, this has been added in Spring Security 5.2 (https://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#oauth2resourceserver-multitenancy).
Spring Security OAuth has been a bit insecure implementation that is why Spring switched to use Nimbus SDK to do the OAuth2 stuff instead of implementing it themselves.
@OrangeDog If you are looking for a multi-tenant IDP feature, this has been added in Spring Security 5.2 (https://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#oauth2resourceserver-multitenancy).
I am simply looking for opaque tokens that are not implemented using RFC 7662
I am not interested in IDP at all - you are exactly proving my point that you have a very narrow view of OAuth. It is not an identity provider protocol!
It is very frustrating, having been involved in the development of OAuth2.0, to see Spring discarding all the deliberate flexibility in a misguided view that if there's no published RFC then it's not a valid method of implementation.
So why are you insisting that the only valid implementation of an opaque token is required to use RFC 7662?
The token may denote an identifier used to retrieve the authorization
information
that's all I want
that's what Spring Security OAuth provides
in contrast, Spring Security lacks even a basic
getTokenDetails(String token) interface
a method, not "the exclusively valid MUST use method"
Which should be obvious, because it was written three years after RFC 6749, and five years after RFC 5849
When I say "opaque token" I mean token as decscribed by RFC 6749
as opposed to a self-encoding token, of which the only common example is JWT
Basically you may do what you want with such opaque tokens. But how do you want to validate these if you do not want to use token introspection? What I mean is that if you do your "own thing" and do not use those standards then you take the risk of being potentially insecure. All these specifications have been written for good reason by some of the best security experts.
i.e. a database
it is no less secure than any other use of a database (e.g. what the system is probably using anyway for user credential and session storage), and in fact more secure than RFC 7662 because it doesn't operate over the open internet
All these specifications have been written for good reason
Again, they are not specifications of implementation details.