I've become very frustrated with the landscape of API creation and authentication/authorization. I would like to find a solution that doesn't require lots of additional complexity (creating new services myself, standing up and maintaining an instance of Keycloak, and so forth) – ideally a managed service (like Auth0 ... but Auth0 doesn't meet my requirements) – that centralizes the management of users and permissions, and allows me to add attributes to users.
Some context:
Suppose you have an API that has a variety of routes:
GET /customers
GET/POST/DELETE /customers/{id}
GET /customers/{id}/orders
GET/POST/DELETE /customers/{id}/orders
You can imagine that you have a case where you have users that have read-only access, and others that can read, create and delete customers and orders. You can also imagine that you may have the need to programmatically access the API, via a service account or access token (such as with Github PATs).
This could be set up with FastAPI or some other framework, such that when a route is accessed it checks that the user, or the access token – or in essence the credentials being used to access the API – has the necessary permissions.
What would be ideal, then, is to have a system that allows me to create users, and from that system the users can – provided they have the permissions in the identity management system to do so – create machine credentials (again, like with Github PATs, but perhaps something that can generate a JWT for consistency of credentials). Users can be added to groups that provide them with roles, and therefore permissions, or they can be assigned roles directly. Ultimately, it's a system that:
Allows user creation and management
Allows users to be grouped, groups can have roles that cascade to users
Allows users to be assigned to roles directly
Allow users to create credentials for programmatic access
Does not make management of users, roles, and so forth, onerous
Allows services (such as a REST API) using these identities for authentication to get the permissions and other information associated with credentials. In the case of other information, this could be included as claims in a JWT – this would require a system that allows claims to be added programmatically to the ID token/JWT.
In my experience, the closest thing to this is Keycloak. Unfortunately, it is a decent amount of work to maintain a Keycloak instance. Still, Keycloak does not provide number 4 in the list above. Does anyone else have experience addressing this issue? I would like to avoid have to manage users and permissions myself, because I have limited resources and that isn't my area of expertise.
Similar solutions:
Keycloak – hits most of the points, except for allowing users to create machine credentials. I'd like to avoid having to set up and maintain a Keycloak instance. Not sure if I can add attributes (claims or something else) to a machine/service account JWT.
Auth0 – Hits some of these, but doesn't allow me to add attributes to machine/service account JWTs, although it will add permissions to them (but that isn't enough).
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 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.
What are best practices for maintaining roles (e.g., a user-provisioning role) in a Web application that uses OAuth 2.0 authentication against a Google App domain? These are roles that are tied to a specific Web application, rather than to the domain as a whole.
Is role management at the application level typically done using the application's backend database, once the OAuth Web flow authorization has been completed? I was thinking of using a Google App group to stand in for each role and then verify membership in the group using the Directory API before allowing an action to be carried out. Is this a suitable approach? This requires either a service account with a group-membership privilege or the assigning of such a privilege to each user in the domain with that role, which are steps that would be nice to avoid.
Is there an API to read information about Google App's native domain-level roles for this? Should custom properties on the user's profile be used? If the latter, is there a straightforward way for a domain admin to set these up when provisioning a new user in the domain, or will a separate UI need to be built out? I've noticed that in the user profile information there is a isDelegatedAdmin field, but that field is a boolean, and I have not found anything with more granular information on the roles delegated to the user account.
We are a service provider. Suppose in our application, we originally have our own user/role management. Different users with different roles are allowed to use different features. So that when a user login we need to know which roles this user has, and prepare appropriate UI. We have administrator role, users with this role can assign roles to other users.
We are thinking of enabling SAML SSO for our application, now the problem is how do we setup roles for each user.
Solution 1, we relies on IdP to provide role information for each login user, the role information may come along with Assertion, but this may not work for all the IdPs.
Solution 2, we only retrieve user from the IdP, and manage the roles in our own application. For example, when we get an Assertion, we retrieve the username(or email address), and match with a record in our DB, if it doesn't exist we automatically create one for this new user. Then we rely on users with administrator role to assign correct role for this new user.
Now the questions is where is the first administrator coming from? Our customer gets our application, and turns on SAML SSO, now there is no users in the DB yet, then how can we resolve such bootstrapping issue? Is there any kinds of standard way? We have come up with different options but not sure which is better and what are the concerns for each options.
Option 1, have a default built-in administrator user. There is a regular native login page that built-in users can login without going through IdP(there is an option to turn it on/off if SAML SSO is enabled)
Option 2, during SAML SSO setup, ask for the administrator user name, so that we automatically create this user in our DB with administrator role. Then when this user login through IdP we could match him in our DB.
What are the other options?
For your first question about who should handle the roles. As I understand every customer has your One of your service provider software. And it connects to a central IDP that you own. If this is the case, it feels like its to complex letting the administrators handle roles on your IDP. I would go for number two.
About question number two. I have been in the same situation I can not remember that I have seen a obvious standard solution for this.
What we did was option 2. It works fine but it adds some complexity to the install procedure. We choose it because we would not have a native login page.
I thing maybe I would be better to go with option 1.
You can get the roles from the different directories of your IDP using your authorization layer. It removes the constraints on SAML and gives the same results as your solution 1.