I apologize if this has been answered, but I have been searching for hours, and still don't quite understand. This is a specific question, and not a "which is best" question.
Specific questions are in italic.
I have created a RESTful API, which was at first meant to be completely open. However, the organization has now decided to create a first-party mobile app to consume and (to some degree) update the data.
I am investigating authentication frameworks (oAuth2), and was not sure if oAuth2 was the correct way to go to meet our goals. And, if it is, which Authorization Grants applied to which set of users.
Our goals are:
To allow users to login and create accounts in the first-party app, entirely through oAuth 2 providers (twitter, facebook, google). These users would have access to the greatest set of data via the first-party app.
Assign different roles to the users (admin, moderator, etc).
Allow other applications to register, receive token credentials, and have limited write access or expanded access to the data. This would open them for creating third-party apps or research systems.
Finally, we would like to keep some of the data completely open, with no authentication needed.
So, am I right in assuming that we want to setup an oAuth2 *Server* (Authorization and Resource Server)?
If so, which Authorization Grants apply to the above situations?
One last question: For users using the first party app, would the app be responsible for logging them in and keeping their access credentials? The API server serves NO html, and is 100% RESTful. Does it need to serve login forms?
If you need to both authenticate and authorize users to your API based on various OAuth2 social logins, you do need some kind of API server or service where you can define your users and groups/role and the scopes that are available to users based on your rules.
Some cloud-hosted options for this are:
Auth0
Firebase
If you integrate with a service such as the ones above, you can let the service take care of authenticating users and just make sure that every user call checks against the service first for permission before it goes ahead and does anything.
Related
I'm developing an ASP.NET Core API, and I'm trying to do the authentication and authorization part as best as I can. I'm studying OAuth 2 and OpenIDConnect (very preliminary studies at this point). But from an API developer standpoint, what can I gain from inserting an Identity Provider like Auth0 or Azure AD B2C in the process instead of just storing the user credentials using some form of cryptography?
Also, Oauth 2 seems to allow many flows, is the job of the API to be concerned with the flow of the application consuming that API? Seems a bit unreasonable. What I want is just to have a safe way to store the user credentials, and allowing the users of my API to perform authentication and authorization before consuming and manipulating resources within the other services within the API.
I understand that authentication and authorization is a sensitive topic within an application, as they deal with security concerns, and I'm planning on building an application that will deal with sensitive financial operations. That's the reason I wend after Auth0 and Azure AD B2C. But to be honest I'm having a little trouble trying to understand what Identity Providers like these will bring to the table, I know they'll bring something of importance, I just need some help to see what and why should I use them.
what can I gain from inserting an Identity Provider like Auth0 or Azure AD B2C in the process instead of just storing the user credentials using some form of cryptography?
Well, you get the freedom of not storing credentials in your database.
Most likely these service providers are taking better care of their security than you would.
Another thing that you gain is Single Sign On.
Many apps can use the same identity provider for the users, so the users only need to sign in once to use all of the apps.
Of course it is not zero cost, there is complexity involved in OAuth/OIDC.
But neither is building your own user store.
Also, Oauth 2 seems to allow many flows, is the job of the API to be concerned with the flow of the application consuming that API? Seems a bit unreasonable.
No, the API usually does not care what flow the caller uses.
What it cares about is that it receives a valid access token that contains the necessary permissions to access a particular resource.
It is a concern of the client app to choose the flow to use.
But to be honest I'm having a little trouble trying to understand what Identity Providers like these will bring to the table, I know they'll bring something of importance, I just need some help to see what and why should I use them.
Well, here are the things that come to my mind:
Better security (most likely, it isn't only about the password hashing algorithm etc.)
Better SLA (building a 99.95% SLA service like Auth0 is not cheap)
Proven track record
Single Sign-On
Single identity for users to all your apps, can easily disable their account as well to prevent access to all apps at once
Can easily add support for federated authentication with other identity providers
No need to store password hashes etc. in your app
Ready-made administration tools (which you need to build otherwise)
To add to #juunas:
AI to proactively monitor user access and disable dodgy logins e.g. logging in from USA and Russia a minute apart
Reporting and stats.
Password protection e.g. not allowing password that has appeared in a breach
Portal and API for user CRUD
MFA
Self-service password reset
Passwordless support
Fido 2 support
Iam working on a flutter mobile application where i use Google SignIn for Auth, is there a way to authorize users with existing account only?
Prevent users from creating new accounts? I've looked for the same thing without finding a way to do this with any Firebase project setting.
The solution, I believe, is consider the difference between authentication and authorization. Firebase's Authentication service is aptly named. It does authentication
- validates that a user is actually who they claim to be. It does not do authorization - control what actions authenticated users are allowed to perform or what data they can access within an application. App developers have to be responsible for managing user authorization.
One way to do this is to maintain a collection of "authorized users" in Firestore, for example. When a user authenticates, your app would perform a lookup to see if the current user is actually authorized or not. Security rules can be written for Firestore and Firebase Cloud Storage to also validate that the current user is in the "authorized users" collection before allowing access to data. But this requires extra data queries to obtain this authorization info.
The authorization method I prefer is to use Custom Claims which can be assigned using the Firebase Admin library. A custom claim can be added to an existing user account that can act as a flag indicating what type of authorization they're granted. Front-end code can check the authentication token they've been issued for the custom claim to determine the authorization they've been granted. Server-side code and security rules can also check for those required custom claims within submitted requests.
Realistically, any application you build where different users might have different levels of access will require you to deal with authorization. I believe that assigning carefully thought-out custom claims is the best solution.
I am building an API meant to be sold to various clients. These clients will be given an API Key or something similar and they'll use the API in a widget on their website.
The end users of the clients' website must be able to use the widget anonymously (no login).
Workflow:
My current idea is to have the Client's server retrieve a temporary key and use that in the webpage. The End user's browser will use that temporary key to call our API.
Is there any reason why this is not a good practice and/or insecure?
Or is there a better good practice solution? Can I for exmaple use OAuth 2 for this?
You need to secure your API from the clients app. So, for that you can use OAuth 2 with Client Credentials grant type and setup each client as an app so they each get their own set of key/secret credentials.
Since you don't know anything about the end user, but still need to track them, require an endUserId custom header on every request to your API and you'll just have to trust the client to provide you with a valid id for the end user making the request.
To setup OAuth, use an existing library or OAuth service. I don't recommend writing your own. If you can spend some money, Okta and Auth0 are good choices. If your API is written in .net, you can use IdentityServer as a free option.
We have a need to secure our .net web api using open id and OAuth standards. IdentityServer 3 is perfect for us as we have to use our existing user store.
Edited for more clarity:
Our company services multiple customers. Each of our customers have their own database. In our home grown client application when a customer user enters their user/password, we do a lookup to authenticate and that also determines what backend database the app connects to.
We now have a need to allow a couple of trusted partners to access our database resource for specific needs. We have created a web api for them to make specific calls. The web api needs to know what customer the partner is making the call for. The partner is calling the api from services on their side so there is no user interaction.
I am trying to determine the flow to use to accomplish this. I found some pretty good info on flows at https://gist.github.com/jawadatgithub/638c11f08ecc0d76b05c.
If I define the client using the Client Credentials flow, I don't know how for them to pass the customer they are making the calls on behalf of. I don't think we want to definate a "Client" for every partner/customer combination, but is this the correct way?
What we had thought of initially is to give an additional user/password or secret key that would tell us the customer, but I am not sure what "flow" for the client would allow this.
Any help or direction would be greatly appreciated.
In case this helps anyone else, we decided to go with a Hybrid flow for these types of requests. We considered designating a service account (user/pw) for each of our customer databases that would give this trusted 3rd part access to them by requesting tokens with the Resource Owner Password Credential flow, but decided against it. We decided against it for all the reasons the standards say not to use it for this use.
If the 3rd party wants to interact with us on the behalf of one of our customers, then they will need to build the UI on their side to redirect to us for user/pw authentication and consent.
I've been reading a lot about the topic but all I find are obsolete or partial answers, which don't really help me that much and actually just confused me more.
I'm writing a Rest API (Node+Express+MongoDB) that is accessed by a web app (hosted on the same domain than the API) and an Android app.
I want the API to be accessed only by my applications and only by authorized users.
I also want the users to be able to signup and login only using their Facebook account, and I need to be able to access some basic info like name, profile pic and email.
A possible scenario that I have in mind is:
The user logs-in on the web app using Facebook, the app is granted
permission to access the user Facebook information and receives an
access token.
The web app asks the API to confirm that this user
is actually registered on our system, sending the email and the
token received by Facebook.
The API verifies that the user
exists, it stores into the DB (or Redis) the username, the token and
a timestamp and then goes back to the client app.
Each time the
client app hits one of the API endpoint, it will have to provide the
username and the token, other than other info.
The API each time
verifies that the provided pair username/token matches the most
recent pair username/token stored into the DB (using the timestamp
to order), and that no more than 1 hour has passed since we stored
these info (again using the timestamp). If that's the case, the API
will process the request, otherwise will issue a 401 Unauthorized
response.
Does this make sense?
Does this approach have any macroscopic security hole that I'm missing?
One problem I see using MongoDB to store these info is that the collection will quickly become bloated with old tokens.
In this sense I think it would be best to use Redis with an expire policy of 1 hour so that old info will be automatically removed by Redis.
I think the better solution would be this:
Login via Facebook
Pass the Facebook AccessToken to the server (over SSL for the
android app, and for the web app just have it redirect to an API endpoint
after FB login)
Check the fb_access_token given, make sure its valid. Get user_id,email and cross-reference this with existing users to
see if its a new or old one.
Now, create a random, separate api_access_token that you give back to the webapp and android app. If you need Facebook for
anything other than login, store that fb_access_token and in your
DB associate it with the new api_access_token and your user_id.
For every call hereafter, send api_access_token to authenticate it. If you need the fb_access_token for getting more info, you can
do so by retrieving it from the DB.
In summary: Whenever you can, avoid passing the fb_access_token. If the api_access_token is compromised, you have more control to see who the attacker is, what they're doing etc than if they were to get ahold of the fb_access_token. You also have more control over settings an expiration date, extending fb_access_tokens, etc
Just make sure whenever you pass a access_token of any sort via HTTP, use SSL.
I know I'm late to the party, but I'd like to add a visual representation of this process as I'm dealing with this problem right now (specifically in dealing with the communication between the mobile app and the web api by securing it with a 3rd party provider like facebook).
For simplicity, I haven't included error checks, this is mostly just to outline a reasonable approach. Also for simplicity, I haven't included Tommy's suggestion to only pass your own custom api token once the authorization flow is over, although I agree that this is probably a good approach.
Please feel free to criticize this approach though, and I'll update as necessary.
Also, in this scenario, "My App" refers to a mobile application.