Im trying to add user roles into my spring security application(the end goal is to make a role for paid users). Im using oidc for authentication. I have 3 different applications, one client, one resource server and one custom auth server(used to login with username and password). I have also integrated google as login option directly into my client application. looks like this. Both using authorization code flow.
The problem I encounter is how to integrate user roles the best way. Because Im thinking that all users should be stored at one place.
When users login/registrer with username and password I can get/store the account in the auth server's database. But when someone uses google I have no idea how to store the user.
My questions is:
When someone login with google my client and google are communicating. But is it possible to somehow make my custom auth server act like a "middle man" so I can store and get data, probably from the jwt token? That would be great for implementing my user roles.
Yes, this "man in the middle" is pretty common. It is called identity federation.
Quite a few OIDC authorization-server on the market support "social login" (login with Google, but also Facebook, Github, etc.) and role management.
Keycloak is a famous "on premise" sample, but there are also many SaaS ones like Okta, Auth0, Amazon Cognito,...
Related
I'am working on an project where we have a Vue.js Frontend and a Microservices architecture for the backend hosted in Azure Service Fabric.
We wan't to add an IdentityService for authentication using IdentityServer4.
What we want to achieve is a login that is basically the same as stackoverflow provides:
You can login on the website with an embedded login or use external providers like Google and Facebook.
My question only concerns the embedded login.
I have read articles that state using Authorization Code Grant with PKCE is the best way in my scenario. Moreover they say, that Ressource Owner Password Grant should not be used.
But as far as I know, with this flow it is not possible to embed the login to our own website. It will always be a redirect to the IdentityService.
How do Stackoverflow achieve this? Do they use Resource Owner Passwort Grant?
Thank you!
First of all, I welcome you to check how Stackoverflow (SO) handle their user registration process.
SO allows you three options. Login through Google, Facebook or register directly to SO. When someone use Google Or Facebook, SO uses Authorization code flow. User is redirected to respective login page. Once you login there, SO receive user profile details from those identity providers, which allows SO to complete the profile and onboard the user.
But when someone use built in register page, it is simply good old registration page. There is no OAuth involved there. SO obtain end user credentials, complete the profile and save them at their backend.
In your scenario also, you can omit OAuth and use a built in registration or login page. Only concern is the maintenance burden of end user credentials.
I am reading about oauth2 now, and trying to understand its purpose. From all the resouces I read, it seems like oauth2 is only used when a webapp (say a game app) that has some users and the app wants to access a user's Facebook or Google data (some sort of data such as name or email, etc). This part is clear to me. However, things that remain unclear to me are the following:
For example: If I have a webapp, and I want the users of my webapp to log into the webapp with their login and passwords (just like how you do it with gmail) without using any third party. Does oauth2 also serve this type of authorization?
I have seen webapps, where they just let users sign up with IDs and passwords, then they salt the passwords and store the salts in the database. So when a user logs in later, they salt the password the user entered, and compare this salt to the salt in the database (created during the signup). If equal, then the user logged in. This does NOT seem like oath at all to me. So if this is not oauth, what standard is this? And are there any other standards for "direct login" like this?
Assume that I want to allow users to sign up and log in to my website, but let them log in via a third party (like Facebook or Google). This is just for authorization purposes and assume that my app has no plan to post on their facebook or request their facebook data except that I may want to use their facebook email as the user ID for my webapp. Does oauth2 serve this type of authorization?
Sorry for the naive questions, because I only read about oauth recently.
For sign-up/login without 3rd-party, as Kevin pointed out, each programming/web framework usually comes with a popular library that once, it will generate all the sign-up/login pages, database tables, flow, etc., for you. The only thing you then do is call a method provided by the library that returns the current signed in user, in your backend code when you need to figure out who the user is.
Using salted password scheme is NOT related you OAuth2 at all as you pointed out. It is a widely used scheme for local authentication because it has many benefits but I will just highlight 2 here:
a. A password when transmitted from user to server for authentication over the Internet is not sent in cleartext but rather in hashed format. Thus even if it were eavesdropped, the password will not be divulged.
b. Since each password is salted, even 2 same passwords will not have the same hash because each have different salt. Thus even if a password hash was eavesdropped, it cannot be reused at another service that the user uses the same password because the other service expected a password hash generated with a different salt.
OAuth2 is all about Authorization (asking a user for permission to perform something on her behalf at another web service, e.g., ask a user for permission to access her email address registered on Facebook). Using it for Authentication can be insecure (for OAuth2 implicit flow). Why? The end result of OAuth2 is an access key associated with a permission, e.g., 'permission to access email address'. When you use the OAuth2 result (access key) for authentication, it means that you are making the assumption that 'permission to access email address' means the user successfully authenticated with Facebook, which she did, so it seems fine. However, imagine if another site also uses OAuth2 for authentication as you did; if it receives an access key with 'permission to access email address' it will assume that you have authenticated with Facebook so it will grant you access to the account belonging to the email address. You could actually use the access key you got from a user, and login as her in the other site, and vice versa.
To use OAuth2 for authentication, you need to use it with OpenID Connect (OIDC), because the end result of OAuth2-OIDC contains an id_token with the aud (audience) field identifying who the access key is for (https://openid.net/specs/openid-connect-core-1_0.html#IDToken), which prevents the access key from being reused where it is not intended. The full explanation with easy-to-understand diagrams is here: https://www.slideshare.net/KhorSoonHin/the-many-flavors-of-oauth/36?src=clipshare
Another very simple but perhaps unnerving to a security-conscious way to do use OAuth2 for login is to use the Resource Owner Password Credential, where your website acts as a middle-man between the user, and OAuth2 provider (Facebook).
Show 'Login with Facebook' button
When user clicks on button, prompt user for Facebook username/password
Use the username/password to login to Facebook to confirm authentication and get access token.
If you don't have to time to read in-depth about OAuth2, perhaps this side-by-side comparison of all the OAuth2 flow can help.
This is courtesy of https://blog.oauth.io/introduction-oauth2-flow-diagrams/
You could use OAuth for local logins like this, but you don't have to. It might be easier, depending on available libraries, and it might make sense if you anticipate making your service available to third-parties in the future. For many sites, though, using OAuth for local logins would be overkill.
Standards are most useful when different actors need to speak a common language so they can interoperate. For local logins you don't need a standard because you're not interacting with any third parties. Many web frameworks include their own variation on the same basic flow.
I think you're asking whether OAuth makes sense for authentication (establishing identity) when you don't actually need any authorization (permission to access third-party resources). It can indeed be used that way, but lots of people will warn against it since it wasn't designed for that and has some security weaknesses in that context. See, for example, Common pitfalls for authentication using OAuth.
I'm developing an application where Google Drive will be used to manage some documents. The idea is to create a document with some initial template data and provide the users access by adding them as collaborators of the document.
I'm familiar with the OAuth authentication process, I used it in another part of the system to manage the users Calendar...
But in this case these documents will be stored in a generic account of the company, so I can't have the approval prompt for authentication, since users won't have the password of the account.
I'd like to directly authenticate in this account, could be with the username and password hardcoded in the Java code.
Problem that this method of authentication was depreacated and I didn't found a relpacement.
Any ideas?
Thanks in advance,
Phillip
There are 2 ways that comes to mind:
Service accounts: best suited for server side OAuth with traditional backend
Regular Account owned by the application : similar to the process already in place for client side Oauth that you are already familiar with; Auth, store the refresh, ask new token if the AuthCode is expired, and so on.
I personally use and prefer the second solution more as I feel is more flexible to adapt in the future for Oauth Client Side get the tokens and use them server side.
Should I use oAuth, for example LinkedIn or Twitter, as my signin mechanism for my app? It seems that most apps just use oAuth to connect other services to it, but they make you set up your own user/password after you use oAuth (including StackOverflow), and I'm not really sure why this is. Would love some insight here. Thank you.
Why not use OpenId, to allow people to sign into your application, without having to type any specific login/password ?
Quoting the corresponding wikipedia entry :
OpenID is an open, decentralized
standard for authenticating users
which can be used for access control,
allowing users to log on to different
services with the same digital
identity where these services trust
the authentication body. OpenID
replaces the common log on process
that uses a login-name and a password,
...
BTW, that's exactly how one logs-in on stackoverflow ;-)
OAuth purpose is not authenticating your users with your site, is letting your users allow you (the oauth consumer) access to their protected resources in other sites (oauth providers) like LinkedIn, Twitter, Google APIs etc.
For authentication, you should use OpenId as others have pointed
Twitter provides a Sign in with Twitter flow that is OAuth but provides a faster redirect if it is an existing user of your service and they are already authenticated with Twitter.
http://apiwiki.twitter.com/Sign-in-with-Twitter
If you are building a Twitter centric application this makes a lot of since to use and you won't have to implement an entire alternate authentication method like OpenID.
Be careful if you let users authenticate with both Twitter and LinkedIn as users will inadvertently create two accounts and need them to be merged.
Facebook and Twitter both have the "Login with Facebook/Twitter" APIs to actually allow users to login without having to create an account for your website. Both of them will return you a valid session that may (or may not) expire. So you actually wouldn't have to ask users to decide on a username/password, as you can fetch both from the APIs (you can not get the users email address when using Twitter though)
So why add those functions to your website?
Users are in general more likely to hit the "Login with ..." button than going through the whole mail address authorization process and entering their name, etc...
Linkedin only has OAuth for usage to its API. It will also depend on what type of language you are writing your webapp in, they should have premade wrapper libraries you could tap on to.
Most Oauth implementations require the user to login with the originating site in the process.
An example is: http://code.google.com/apis/accounts/images/OAuthDiagram.png
What if I want to use my own account to access a generic feature, such as a search for people outside of my network, and don't want them to login? Is there any way to login with my own generic account?
I am creating a web service that interacts with many social networks by searching them, so by forcing the user to login several times to each network if I want to use their API is just bad user experience.
You could try to authenticate your account manually and then store the access token. Any subsequent request would be made with the stored access token.
There are several problems with this approach:
if the token expires, you have to reauthenticate
you might run into request quotas if you do all requests from one account (e.g. Twitter)
If possible, I would use something like HTTP basic auth to authenticate to the services.
When you are strictly speaking of OAuth, it is not meant for this scenario. Try looking into SSO (Single Sign-On).
OAuth can also be implemented in conjunction with SSO solutions.