What I'm trying to do is to create an application with Angular frontend and Spring Boot backend with OAuth2 authentication.
The issue is that I don't know how to get on the frontend the ROLES user has so that I'll be able, for instance, to show something role-based on the page. Yes, there are scopes that OAuth provides in the response but the problem is that these scopes are for the CLIENT but not for the specific USER itself. And that CLIENT is my frontend side (correct me if I'm wrong) which basically means that every user operating my application(client) going to have the same scopes(roles). Moreover, I can specify roles on the backend with the help of Spring and UserDetailsService and then use those roles with #PreAuthorize, etc. But not on the frontend side.
Just as an example, if I simply used single JWT then with a token itself I'd return both the username and roles to frontend. And then I could store that data and use it on the frontend side according to my needs.
So what I'm asking is if it's actually possible and if this is correct to do so?
And how can I possibly implement such behavior?
OAuth doesn't solve this problem and it is best solved via claims in your API. OAuth should deal with authentication only. My below post may help you to think about the best separation: https://authguidance.com/2017/10/03/api-tokens-claims/
In a nutshell you will have to look up user rights such as roles after the OAuth processing completes.
There is a great video from Spring developer on YouTube about OAuth2/OpenID Connect. It shows how to implement the resource server using the newest Spring Security 5 solution.
Probably the easiest and the best way to achieve this is to use an OpenID Connect server which will provide all user management stuff. On the market there are many solutions. Auth0 and Okta are Identity Clouds which provides their services for small amount of money. On the other hand you have Keycloak, which is a server which you can install in Docker or even on bare metal - it's free and open-source.
Related
I have already set up a running application having:
an authentication server
several resource servers
a javascript-frontend
For the authentication I am using the oauth2-stack of Spring-Security to hand out JWT-tokens to successfully authenticated user's. The login-information is collected in the javascript-fronted which then asks the authentication-server for an auth-token and stores it. This all works well for my application.
What I want to do now is integrate third-party-login-services like Google or Facebook. Currently I am at a point where the process can be started from the javascript-frontend, then the authentication-server does it's magic and communication with the third-party-login-provider. I've gotten so far that the login process is successful and I get the needed information which actually is only the e-mail-address.
But now I'm stuck. I have the authentication information on the server but now I need to construct one of my own authentication-JWT-tokens and hand it to my javascript-frontend. Can anybody give me a hint on how to achieve that?
The JWT Login Sample in Spring Security Samples demonstrates how to create JWT tokens for your own purposes. The key is to ensure that authentication has already occurred, prior to provisioning said token (which in your example is already the case).
Note that the sample uses the com.nimbusds:nimbus-jose-jwt dependency as Spring Security already depends on this library internally. You may also consider using io.jsonwebtoken:jjwt-api or another library instead. jwt.io has a useful list of libraries that support creation of JWTs, and you can filter by Java and click through to the repository to get more information about any of them.
In any case, the sample should be easily adapted to your choice of library, and the out-of-the-box support for verifying JWTs in Spring Security should work.
I'm evaluating Auth0 as an authentication/authorization service for our new project.
I would like to expose some REST APIs without UI at this point.
So I believe clients won't need to log-in but just send an authorization header with a JWT token (I'll send this token by e-mail at this point).
I understood that in Auth0 there are "non-interactive" clients for this (Am I right?)
In my understanding, every potential customer will be a client and I'll create a dedicated client configuration in Auth0 for it.
So I've created a client like this following the tutorial found here
(we've a java shop, so I've naturally opted for spring security) and it works.
Now I would like to put some metadata on such a client. I've tried to add the "Application Metadata".
I would like to access this metadata on server (from java Spring rest controller), but I see that its not in the JWT token
My question is what is the right implementation for this? How should I get this information on server?
Thanks in advance
I think you're mixing the notions of "Clients" and "Users". A Client in Auth0 is an access channel to the Auth0 back-end. In some (unusual) approaches to multi-tenancy you might go with multiple Auth0 clients, but I doubt it.
What I think you want is: One (1) Client and many Users.
The app_metadata are then associated with the User records.
I am searching for the best approach of authenticating users of mobile clients when accessing my RESTful API. For example, how approximately AirBnb uses it's auth module.
Should the authentication be different for RESTful and basic session-based resource, working with the same data?
I am not a mobile developer therefore, I am interested in what is the best way to provide authentication from server-side, so the mobile-platform developers could use it simply.
I googled for few approaches using OAuth, OAuth2, HTTPBasic authentication and still wonder how the mobile developers can use such API, how they will store this token (cookie is stored by browser in browser-oriented apps).
Could you please suggest me some links/code samples/techiques that you used in production or pet-projects or something?
An easy and manageable alternative to OAuth(2) for authentication is JWT.
You don't need additional infrastructure, the workflow and use is straightforward and there are ready to use libraries for all major languages already available.
Compared to HTTP Basic Authentication JWT is more flexible by transmitting additional information not just credentials, you can store the JWT token as JSON or you can use cookies, you don't need to store the credentials on client side and you don't transmit the credentials on every request.
Also based on JWT you can realize very easy a single sign on function. So if you need more than just a simple system user then you should definitely try JWT.
We are implementing Single Sign On [SSO] across multiple applications, which are hosted on different domains and different servers.
Now as shown in the picture, We are introducing a Authenticate Server which actually interacts with LDAP and authenticate the users. The applications, which will be used/talk to Authenticate Server are hosted across different Servers and domains.
for SSO, I can't use session variables, as there are different servers and different applications, different domains, a domain level cookie/session variable is not helpful.
I am looking a better solution which can be used for SSO across them. Any demonstrated implementation is existing? If so, please post it or point me in the right direction for this.
You can achieve this by having all your log-ins happen on the auth server. The other applications can communicate to the auth server through a back channel. The general principle is like this:
User accesses application 1.
Application 1 needs the user to sign on, so it sends a token to the auth server through the back channel. Application 1 then redirects the user to the log in page on the auth server with the token as a parameter on the request.
User logs in to auth server. Auth server sets a cookie, flags the token as authenticated and associates the user details with it. Auth server then redirects user back to application 1.
Application 1 gets request from user and calls auth server over back channel to check if the token is OK. Auth server response with user details.
Application 1 now knows that the user is authorised and has some basic user details.
Now this is where the SSO bit comes in:
User accesses application 2.
Application 2 needs the user to sign on, so it sends a token to the auth server through the back channel. Application 2 then redirects the user to the login page on the auth server with the token as a parameter on the request.
Auth server sees that there is a valid log in cookie, so it can tell that the user is already authenticated, and knows who they are. Auth server flags the token as authenticated and associates the user details with it. Auth server then redirects user back to application 2.
Application 2 gets request from user and calls auth server over back channel to check if the token is OK. Auth server response with user details.
Application 2 now knows that the user is authorised and has some basic user details.
There are some existing implementations of this method, for example CAS (Central Authentication Service). Note that CAS is supported out of the box in Spring Security. I would advise you look at using an existing implementation, as writing your own will be hard. I have simplified things in my answer and there is a lot of potential for introducing security holes if you're new to this.
I will recommend you check out OAuth. It is a good Authenticaiton and Authorization protocol used by several large organizations including facebook, google, windows live and others. It may have an initial learning curve, but it is a production grade solution.
It also has libraries for Java, Ruby, PHP and a range of other programming languages.
For example, the following server side implementations are available for Java.
Apache Amber (draft 22)
Spring Security for OAuth
Apis Authorization Server (v2-31)
Restlet Framework (draft 30)
Apache CXF
Following client side Java libraries are also available:
Apache Amber (draft 22)
Spring Social
Spring Security for OAuth
Restlet Framework (draft 30)
Please refer here for more details:
http://oauth.net/2/
http://oauth.net/documentation/
The bigger question is how you are implementing single sign on. Many open source and even proprietary (IBM Tivoli) offerings worth their salt offer cross domain single sign on capability. This would be the easiest and best way to implement cross domain sso. You can configure the LDAP server you use in the sso server you choose.
Taking for instance open sso, here is an article to configure cross domain single sign on
http://docs.oracle.com/cd/E19681-01/820-5816/aeabl/index.html
To configure LDAP in open sso,
http://docs.oracle.com/cd/E19316-01/820-3886/ghtmw/index.html
Reference on the issue is presented in a neat diagram here
http://docs.oracle.com/cd/E19575-01/820-3746/gipjl/index.html
Depending on which offering you use, you can configure cross domain single sign on.
With this, your diagram will look like this, with the auth server being your utility to interact with sso server of your choice.
Having an auth server that communicates with sso is a sound architecture principle. I would suggest making calls to authenticate as REst end points which could be called via http from different applications.
You cannot use Rest Service .
You could use what i call a Refferer Url Authentication
Say you have a Authentication application running on www.AAAA.com
In the applications , where you want to authenticate , you could have a filter which looks for a authenticated cookie in its domain else redirect to www.AAAA.com for authentication
On Successfull authentication , you could pass the user profile information as encrypted GET / POST data back to the application
Since I have built a Java application, I have been looking for an SSO solution for it. I found a free Java SAML Connector using which you can achieve SSO in java based applications built using any java framework.
Here's the link to it - https://plugins.miniorange.com/java-single-sign-on-sso-connector
I'm reading the Google Cloud Endpoints docs related to OAuth2 Security.
I assume this kind of security is against Google accounts.
Is there any support to have a custom User schema to authenticate against?
What I would like is to have client JS application which uses Google Cloud Endpoints but authenticate against local storage (App Engine) of users.
Is Google Clound Endpoints suitable for this or do I need to write my own Security mechanism?
My understanding of OAuth is:
An end point is implemented by a provider, so when an application such as yourself, authenticates a user such as myself, it returns a result.
Now the problem is if google's end points can return custom schema.
What you could do is, implement the functions, and change your DNS (/etc/conf) so that google's endpoints hit your localhost. In principal this will work, however in practice I am not sure I would do this myself, but perhaps you have your reasons.
So with AppEngine, I imagine there might be a class which overrides/implements this stuff. With the DNS rewrite trick, you should be able to get it to work.
If you do, please write about it, so it can help others.
The OAuth for Cloud Endpoints is Google accounts only. You would have to write your own.
Honestly, just use Google Accounts, user can even sign up for Google accounts with their own email address. In the future they will probably support Open ID with Endpoints as well.