I'm trying to figure out which OAuth2 grant to use for my application/saas. Or if OAuth2 is even the correct way to go.
The application:
The purpose of the application is for use and integration with e-commerce. So what I want is for the user is to go to my site and register an account. After the account has been created the user should be provided with credentials with which he/she can acquire an access- and refresh-token. The access-token should provide access to the users OWN resources and preferably use scopes to limit access. The user should the be able to get/post/put and delete stuff from his/her account as if working in the provided administration (SPA).
They should not have to go through the OAuth redirect flow, because they will be using the API from their servers.
My thoughts
First I considered going for the Client Credentials grant. But then I found out that it will not provide access to a user and it's resources.
I've started leaning towards using the Resource owner credentials grant. But I don't put a lot of faith in my users picking strong passwords. And in almost all documentation I can find, everyone seems to not recommend using this grant.
Maybe OAuth is not suitable for my project? Maybe I should go for some API Key which can be traded for an access token?
Any thoughts and/or input?
I've one link which may useful for you.
Link: https://github.com/lucadegasperi/oauth2-server-laravel/blob/master/docs/authorization-server/choosing-grant.md
Came to the conclusion that OAuth2 was not correct for my situation.
In the end I chose to go with a custom solution based on JWT.
Related
I am writing a REST API and I want to authenticate users with Auth0. I also wanted the users to be able to get a list of all the users registered in the tenant (just basic information, maybe even just username) and I saw that there is Management API for this.
I'm a bit confused about how to grant read access to the Management API to all the users, but I thought about a couple of possibilities:
grant read access to each single user
expose endpoints in my API to proxy requests towards Management API, so that I can use client credentials grant
use a post login action that adds basic user information to my private database (I don't like this, I'm foreshadowing sync issues)
Which one should I use (or maybe a further one)? I'd also appreciate basic guidance on the solution that you suggest. Thanks!
You should not need to grant your users access to your management api. Instead you should use your client credentials to get an auth token to use for this. In fact, the Auth0 docs have recommendations about how to use the management api in your application.
If you wanted to add user authorization on the routes that use the management, you can simply verify tokens and user roles as you do on other routes of your API. But you (typically) shouldn't use the user tokens as your tokens to access the management api.
First of all, I apologize in advance for my naïveté on the topic.
I am trying to create a few microservices that are exposed using an API gateway. A few of these services will need credentials from Google account to access Google Calendar/Gmail etc.. is there any way for a user to only have to login once so that the credentials are all shared between the services? Or should only one service be facing the Google services with credentials?
It seems possible, you can ask a user to authenticate and authorize all permissions your application will need, all at once. But think about the user, when an application requires to access gmail, hangouts, photos, camera, etc. at once, the user normally disbelieve the application. So, the recommended approach is asking for the specific permission when the application requires it so that the user can realize each action you app do.
There exist many different ways to address your question depending on details, however the following link can help you to know where to start:
This link (Google Sign-in) has a wide context on all the Identity mechanisms to look for the most appropriate for you.
This another one explain all possible Identity mechanisms for specific use cases.
This authentication example for Google Calendar is useful, but this post explain how microservices authentication and authorization was solved.
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.
Ok, Having read so many QAs here about OpenId and OAuth (like this, I hope I understand the difference between both. I see people recommending OpenIDs for authentication (proving identity) and OAuth for authorization (say tweet or post something to fb wall,etc).
But my question is- how about using Facebook/Twitter OAuth for authentication to a website? like the way SO itself uses Facebook login as an identity of a user. I'd like to hear what is others opinion about using something meant to authorize to use to authenticate. The reason why one might want to do is the same as using Open Id i.e., to ease the registration process for a new user.
PS: Please correct me if I'm still confusing the use of OpenID/OAuth.
You are not confusing anything as far as I can see. OpenID is indeed a specification for identity authentication, and oAuth is indeed mostly aimed at solving authorization problems.
That having been said. You CAN use oAuth for identity authentication as well. There is nothing to stop you from doing that. I for one will definitely leverage that.
There only drawback of using oAuth for identity authentication is that you may want providers to be strict with what their access tokens allow you to do. What I mean is, when you authenticate a twitter user, you will also be able to do everything else that the Twitter API allows you to do (which is basically everything). Facebook is potentially more restrictive and authenticating applications can be granted only a subset of API functionality.
OpenID does identification, and that's pretty much it, I love it. But I'll gladly use oAuth for the same purpose any day of the week.
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.