I'd like to setup a central authentication / authorization server using Spring Security from where I could fetch JWT token which I could then use for accessing restricted resources on another Spring Security backed up REST server.
Here's my flow:
1) HTML JS / Mobile etc client authenticates on auth server to get the JWT token
2) Client sends this token in HTTP header to REST server to gain access to secured resources
I thought JWT would suite best for this scenario because it can contain all the relevant data and REST server could be fully stateless and simply decode the token to get all necessary data (role, clientid, email...) on REST server.
Is Oauth2 right choice for this and if so could someone kindly point me to right direction? If JWT isn't the right bet, I'm open to other solutions :) I should mention that in my case it's also possible to load client information from database also on REST server, but it should not be responsible for authenticating the user (meaning no username/password check, just the token decoding/validating...)
The Cloudfoundry UAA is an open source OAuth2 Identity Managemennt Solution (Apache 2) which issues JWT tokens. You could look at the way it is implemented, or just use it yourself, either as a server or just the JARs. It implements a bunch of existing strategies in Spring OAuth. It also optionally has its own user database, or you can implement your own. There are lots of options and extension points and many people using it in various ways (not all with Cloudfoundry) because it was designed to be generic.
Spring OAuth 2.0 also has support for JWT tokens as well, but it isn't released yet (the bulk of the implementation is drawn from the UAA).
However, since you say you don't mind opaque tokens (and a database loookup) you might prefer just to use the JDBC support in Spring OAuth 1.0. It was in use in Cloudfoundry for quite some time before we moved to JWT, so I can vouch for it in production.
As to whether OAuth2 is a good choice for your use case: you are in the best position to decide that. Nothing you said so far makes me think it would be a bad idea. Here's a presentation I did if it helps (you can probably find it on YouTube in the SpringSource channel if you like that sort of thing).
Alvaro Sánchez have developed a plugin with jwt compatibility. http://alvarosanchez.github.io/grails-spring-security-rest/1.5.0.RC4/docs/guide/tokenStorage.html#jwt
Install the current version in BuildConfig.groovy:
compile ":spring-security-rest:1.5.0.RC4", {
excludes: 'spring-security-core'
}
You only must to change the secret option in Config.groovy
grails.plugin.springsecurity.rest.token.storage.jwt.secret = 'YourSecretKey'
And set a chainMap to separate security managed with traditional mode from new rest stateless security.
grails.plugin.springsecurity.filterChain.chainMap = [
'/yourApi/**': 'JOINED_FILTERS,-exceptionTranslationFilter,-authenticationProcessingFilter,-securityContextPersistenceFilter,-rememberMeAuthenticationFilter', // Stateless chain
'/**': 'JOINED_FILTERS,-restTokenValidationFilter,-restExceptionTranslationFilter' // Traditional chain
]
You can to manage authorization and authentication within your application with the spring-security-core plugin.
Related
I am trying to enable OIDC authN and authZ workflow for my spring-java-web application. Ideally I wanted to do it in a IDP agnostic way.i.e.This application could be integrated with only and any one of the Azure AD,OKTA,AWS SSO,Google-auth by deployment admin.And I want users to be redirected to whatever provider the application is integrated with.
With OIDC as a standard, my understanding is i should be able to write a OIDC auth processing filter that should work with any of the providers. The necessary config that varies per provider ( auth url,client id,secret,JWKS url to get the provider keys etc) will be passed to this filter/rest template as parameters.
Q.1 Is it possible to implement provider agnostic OIDC filter? Can someone give any pointers?
I am aware that Spring natively provides Oauth2 libraries/apis like AuthorizationCodeResourceDetails, OAuth2ClientAuthenticationProcessingFilter . However I do not see any OIDC native processing filter in built. Is there any?
I tried and understood the workflow as given in https://www.baeldung.com/spring-security-openid-connect .However when i try to tweak this code to make it work with Azure AD it fails. Thats because Azure AD requires
The response_type parameter must include id_token.
The request must include nonce parameter to be set in request.
AuthorizationCodeResourceDetails does not support such param. Given that OIDC is a common standard ,
Q-2. I fail to understand why every provider still has different requirements? Doesn't it defeat the purpose of OIDC . Infact I read that google throws error if you pass nonce
Q-3. Are there any spring native ways to configure these additional provider specific params like nonce , promt, additional response-type ,preferable with examples?
I think your problems with Spring Security OIDC are that you're using the legacy OAuth library (at least that's what the baeldung article is illustrating). OAuth2 and OIDC are part of Spring Security 5.x now and not a separate project. There's an OIDC client "login-client" in this example: https://github.com/jgrandja/oauth2-protocol-patterns that might show different. Yes, OIDC should allow you to swap providers in and out although not all OIDC providers will implement everything (e.g. discovery, etc.)
We had an web application that already using form-login provided by spring-security, say, ERP. Now we are considering make ERP as an oauth2 authorization server to authorize other internal services.
The ERP still serving its business and all access are required to be authorized, but doesn't based on access token so I think it is not an oauth2 client. It does NOT serve as an Resource Server, neither.
I have read many article about how to setup oauth2 authorization server and develop an application using it. According to this comment I feel it is possible to make ERP authorizing other services without explicit setup a standalone authorization server (it's our final goal but not now):
Within the context of OAuth2, we can break things up according to the component you're implementing:
Client app: it's likely that server based OAuth2 Client app already uses HttpSession and therefore it makes sense to use Spring Session and benefit from all the goodies it brings
Resource Server app: since this component provides a stateless API that's authenticated against using an Access Token as a bearer, the HttpSession is not used and therefore Spring Session isn't suitable as well
Authorization Server app: it's highly likely that this already uses HttpSession so similarly like with OAuth2 Client app, it makes sense to use Spring Session and benefit from all the goodies it brings
What I'm going to do is add the #EnableAuthorizationServer into config, but I have no idea what's the next step.
My question is can I convert an existing application into an authorization server while keeping its original service unchanged? Where and How should I start?
I just found it's not that hard to integrate OAuth2 into existing system, below is what I did to make it work.
In short: EnableAuthorizationServer won't break anything exists, but they don't coming from nothing, either.
When I put on the EnableAuthorizationServer, spring-security-oauth2 gives me following endpoing:
/oauth/authorize
/oauth/check_token
/oauth/token
/oauth/confirm_access
/oauth/error
Those endpoints provide necessary functions to make OAuth2 works, and I just need to apply access control onto those endpoints with existing form login mechanism (probable not the check_token one).
Since this system didn't act as resource-server role, the authorization part is done.
Currently, I think my understanding of OAuth and how it it is implemented in ASP.NET Web Api is flawed.
1) I keep seeing OAuth described as a server (i.e. the OAuth server). Is the OAuth implementation by a Microsoft a separate server with a different port or is it just referred to as a server even though it is self contained within the API project?
2) Is OWIN separate from OAuth or are the two linked such that they must be used together?
3) How does an OAuth v2 server keep track of tokens that have been revoked or have expired? Does the OAuth component have a database that keeps track of the tokens that it issues? If so, what type of database is it?
I have been reading the tutorials by Taiseer Joudeh from bitoftech.net but I think I am missing some of the basics.
Here are my responses:
You can implement the server as a stand alone authorization server or you can implement it together with the resource server. The Visual Studio template brings you both servers together, but you can separate them. Tutorials from Taiseer Joudeh will guide you very well, they did in my case.
OAuth 2.0 is an authorization framework, as said in its definition document. And OWIN stands for Open Web Interface for .NET. Both of them are different things, but Microsoft decided to do an implementation of OAuth 2.0 protocol using OWIN middlewares architecture. Then the easiest way to develop OAuth 2.0 servers in ASP.NET is using Microsoft.Owin.Security.* libraries implemented by Microsoft.
The OAuth 2.0 protocol does not talk about keeping track of expired or revoked tokens, you could implement if you want, but you only could do if the authorization and resource servers are both the same, and then you will need to access to database to check the token for each request, that it is not necessary. If the resource server is separated from the authorization server it has no direct access to the authorization server database. Normally you don't do that. The expiration check of the token is something that the Microsoft.Owin.Security.OAuth library makes for you. If a token received by the resource server has expired, the library responds with a 401 - Unauthorized response.
To make possible that the resource server can decrypt the token, you only need to set the same machine key in both servers' web.config file.
To avoid to have long lived access tokens you could set short access token timespan and implement refresh token. In this case, you could save refresh tokens in database and you can implement some method to revoke them.
Refresh tokens and its revokation are implemented in Taiseer Joudeh blog posts too.
I hope my explanations are clear and can help you. Please tell me if you have any other doubts.
We need to expose a REST endpoint to the outside world to be called by an external service which we don't control. The people responsible for this external service seem to be security experts (not), and so instead of using at the very least HTTP Basic Auth or any other real authentication mechanism, they authenticate themselves using a fixed secret. It goes like this:
GET /endpoint?secret=WE_ARE_THE_TRUE_GUYS
As we're already using spring-security-oauth2, we'd like to integrate this authentication flow with our existing flow so that we can specify rules for this endpoint the same way we do for every other enpoint on our ResourceServer, get the same error handling behaviour and etc. How shall we go about implementing a custom authentication filter - or whatever it may be - that will grab the secret parameter from the query string, transform it into some kind of "client credentials" for a pre-configured client on the AuthorizationServer and integrate seamlessly with the rest of the OAuth2 flow?
If you can transform "WE_ARE_THE_TRUE_GUYS" into a valid OAuth2Authentication then all you need is an authentication filter that does that (and sticks it in the SecurityContext). Then the downstream filters and handlers will behave just as if it was a real OAuth2 authentication. If I were you I would put some very tight conditions in that filter to match the request to one that is on the allowed resources from this highly unusual and not very secure authentication channel.
I am building a REST API using Grails. I want it to be protected using OAuth2.0 client_credentials flow(grant_type). My use-case is as follows:
a external agent will send a request to something like
http://server-url/oauth/token?client_id=clientId&client_secret=clientSecret&grant_type=client_credentials
and obtain a access_token. Then, my URL(protected resource) should be accesible with something like
http://server-url/resource?access_token={access-token obtained before}
I am looking for something that makes doing this on Grails easy and quick. What will be the best way/tool/plugin to use for this ? Scribe library is an option, if there are any tutorials for my specific use-case, it will be great.
P.S.: I have tried the spring-security and related plugins, no joy there. Any alternatives would be nice.
I have the same issue. I found a lot of grails plugins that helped you authenticate your app against other oauth providers, but nothing that would help me make my app the oauth provider. After a lot of digging, I came across this grails plugin that will do exactly what you want.
https://github.com/adaptivecomputing/grails-spring-security-oauth2-provider
I'm still configuring it for my application, and I think the docs might need a few edits (specifically the authorization_code flow) but I got the simple client_credentials flow to work with minimal configuration. Hope that helps!
Based on my experiences, Scribe was built for OAuth 1.0 and has only very limited support for OAuth 2.0. In fact, for testing our own OAuth 2 implementation, all we could use from it was an HTTP request wrapper, we had to do anything else manually. Fortunately, doing it manually is suprisingly easy.
Since I still haven't found a fine open OAuth 2.0 library for Java (frankly I'm not familiar with Groovy), I encourage you to write the client code for yourself. You don't even need a client callback endpoint to use the client credentials grant flow. So you simply create an HTTP request (as you've written above already, take care to escape the GET parameters though) and get the response content. Your flow does not use redirects, so simply parse the JSON object in the response content, e.g. with the org.json library. Finally, send an HTTP request using the extracted access token.
Note that your examples are not completely standard compliant. The standard requires using HTTPS, sending the token in an HTTP header instead of a GET parameter and suggests using a HTTP basic authorization header instead of GET parameters to specify client credentials.
I may have misunderstood your question, and you may want to implement the server side, too. The scribe library supports only client side, so you can find a commercial implementation or implement your own server. It is a complex task, but if you support only the client credentials flow, it almost becomes easy. ;-)
This isn't a plugin, it's just a sample Grails application that acts as an OAuth provider. It was really easy to get up and running with Grails 3.
https://github.com/bobbywarner/grails3-oauth2-api