Spring Security OAuth and Spring Security. UserDetails versus ClientDetails

OK, so I have built a custom UserDetails and UserDetailsService for our application(s). Some of the applications are web, some vert.x. In the vert.x world we can't include Spring Security or Spring Security Oauth for the server side stuff.

But we can create vert.x as a client app.

Anyway, if I am integrating both Spring Security and Spring Security Oauth (if they should even be integrated)

Do I need to create two different classes One for ClientDetails for OAuth stuff, and one UserDetails for SpringSecurity.

I think even for our web application, it should do OAuth for logging into the app, rather than standard Spring Security.

So if we just have OAuth, then I am guessing we only need ClientDetails and ClientDetailsService implementations and "toss out" our UserDetails and UserDetailsService implementations.

I was going to combine our UserDetails implementation to implement ClientDetails also, but the back end data storage (JDBC) would need to change.

Basically, If I am using Spring Security OAuth only, do I need the same fields and tables that I had with UserDetails object?

Thanks

Mark

I think you might be getting confused about the difference between a Client and a User. You still need to authenticate Users (I would guess) so there might always be a place for a UserDetailsService (that's not the only way to authenticate users in Spring Security but it is very common). ClientDetails identify the machine component that is acting (possibly) on behalf of a User. You typically have far fewer of them.

Incidentally I don't see it as being very difficult to use Spring OAuth to secure a non-webapp like in your vert.x example. It isn't the focus of the Spring OAuth namespace support, but plenty of non-web applications use Spring Security already, so it can't be a huge stretch. Please get involved and open a discussion on JIRA or github via a pull request.

Thanks Dave.

In our case there should be exactly the same amount of Users as ClientDetails, as in all of our applications, including the website will be using the OAuth dance for authentication. I think they even want the "login page" on the website to not use the typical way that uses UserDetails. So I guess you could say all our applications are clients of something, I don't think I can say application, but I guess you could say auth server.

Thanks again for your reply and time

Mark

You are welcome. However, there is no scenario I can think of where clients and users are the same thing, and most of the rest of what you said is unclear to me. If you're happy, then I'm happy, but maybe you should take some time to explain what you are doing, if only to yourself, and correlate it with the domain language provided by the OAuth2 spec.

This happens to me all the time. ;)

Yes, we are technically using OAuth in a different way. There is the signing up or signing in to our applications with a provider say like FaceBook. We are also going to be a provider to other applications. But we are also using it as our signin security solution.

And, here is the different way, we are using OAuth in our applications as our security. Meaning when users login to their account in our application, it will use OAuth. Meaning while they will be entering username password, it will not be using the standard Spring Security way, but a whole token access approach. So client==users. We are taking OAuth in our application as the single signon approach. We have at least 5 different applications, on all types of devices, and want a single sign on. Except for the web application, all our other applications are through sockets.

So here is the steps in the iOS app. User gets a signin screen. Enters username/password. It is sent via REST to our OAuth server, which will look up the user, put their security context into Redis and return an access token. The app will then create socket connections to our other servers, (chat server, game server and stats server) When each connection is made it returns a code. Within 20 seconds the app needs to send the code and their accessToken, which we lookup in Redis, if it is correct then they are now connected and authenticated to our server(s) and the sockets remains. If time expires or they don't send the correct data, then the socket is disconnected and the securityContext information is removed from Redis.

The app will go through this handshake process for each server (chat, game and stats)

Does that make more sense. Like I said it isn't exactly what most apps that use OAuth are doing, but it should be usable for our scenario.

Thanks

Mark

I actually think for all that we want to do the UAA is the solution. We can deploy it in our vms and have all our applications authenticate through it.

For storing security context into redis, we would just have to customize it a little bit to store the information of the user security context after they authenticate and get their token.

Thanks

Mark