We're building a new application that will have a user signup and logged-in user area. Authenticated users will have access to our API.
I wanted to separate the user signup OData endpoint from the logged in/API-access OData endpoints.
For new-user signups, a separate in-network API works. However, public-facing, I'd like to know some proven architectural strategies.
I would bet that you could use FormsAuthentication to lock down access based on users and/or roles in your MVC application. OAuth could be used in conjunction to handoff the identifying info to your authentication/authorization routines.
Here is an article on using OData and FormsAuthentication.
Related
I'm designing the architecture for a college project and I don't know how to deal with the user authentication and authorization part of it. The project is a desktop Electron app which would need two types (hence the roles) of users. They both need to be authenticated in order to use the app, and depending on their identity, they will have different authorizations. Since the project is meant to be used by teachers and students as part of a laboratory class after it is done, I don't think more than 30 people will be using it at the same time.
My first thought was using a PostrgeSQL database in AWS for this and implementing the authentication myself, but this means that users will have to sign up and create a new profile, which means remembering yet another <username/email, password>. Trying to avoid this, I read a bit about OAuth 2.0 and OIDC, and how it can be used to authenticate and authorize users without implementing either of those tasks oneself, but rather delegating the task to OIDC. I created a free account with Auth0 and thought about using it for the OIDC integration but after reading about 40 pages of an "OIDC integration handbook" they offer for free, I could not know if I would be able to distinguish my user base through these roles or tags as I mentioned. I just followed the steps in the tutorial handbook and tried to understand how the auth flow worked, but that didn't give me any information on my question.
So all in all what I want to know is: is it possible to implement this with Auth0 (free account) without having to use a third-party database solution (such as PostgreSQL with AWS)? If not, what would you recommend me to look into? Preferrably a solution that will let me discriminate between the two types of users BUT at the same time taking advantage of the OIDC implementation of Google for example.
There are 2 separate solutions here:
DESKTOP AUTHENTICATION
The 2 standard requirements are:
Use Authorization Code Flow (PKCE)
Login via System Browser
You listen for a login response via one of these mechanisms (I prefer the latter):
Loopback web server
Private URI scheme OS notification
My blog has some tutorials + code samples that use Electron. You can run both of the above listening options and see what you prefer.
API AUTHORIZATION WITH ROLES
You need to make roles available to the API via claims. This can be done by either of these mechanisms (I prefer the latter):
Including roles in access tokens via Auth0
Get the API to read user roles from its own database
My Authorization blog post discusses building up a claims object in an easy to extend way. The main objective is usually for API OAuth processing to result in an object something like this:
class UserPrincipal {
// The technical user id from the access token
string sub;
// The user id from your own database
string userId;
// The user's roles
string[] roles;
}
Given that object you can do things like this:
Use role based authorization when needed
Serve up user resources after login from your application data
TO SUMMARISE
Auth0 will meet some of your requirements and may be all you need in the early days. You will probably need to manage non OAuth user data in your API at some point though.
Happy to answer any follow up questions ..
Imagine we have an application that is implemented based-on restFul and OAuth2, and also of course we've stored the user's roles and permissions in the back-end which is implemented by Java and spring boot. So I want to know how can we handle the permissions of users in the front-end. Indeed, there are some fields or columns that should be shown to the user who has specific permission or role but other users can see limited fields or columns.
What is the most efficient and sensible solution to this situation?
Should the front-end fetch available field or columns from the back-end?
Should the front-end has all of the information about user credentials to decide?
or is there any solution to do this?
Here is the most common solution, where all security is enforced by the API:
API responses omit fields / columns that the user is not authorized to access
UI can ask the API which fields / columns the user is authorized to access
UI hides elements based on this API metadata
It is common to have an endpoint such as this, which the UI can send an access token to in order to get the above metadata:
GET /api/userclaims/current
I've done a fair amount of research on the many different ways to authenticate and authorize users who use my frontend application to access my REST API. I've built a system that uses OAuth2 and JWT and need a sanity check since I'm working on this alone.
For a bit of background, my frontend is built using Vue.js and my API is built using Django with Django Rest Framework. My team is already planning on concurrently developing the mobile and desktop versions of this app which both would require authentication and authorization as well.
To keep things brief, I'll omit the alternative solutions I have and just talk about the most controversial one.
Right now, OAuth2 (my authorization server) grants users a JWT token using ROPC when they provide their email and password to my frontend client. I should note that my API (my resource server) and authorization server live on the same machine.
My application allows users to essentially signup using different plans (for example a free plan and a paid plan). When a user signs up for a free plan, I need the frontend application to not only disable certain features and elements in the UI, but also I need the authorization server and or resource server to limit what that user is allowed to query based on their plan.
The idea is when a user signs up or logs in, my authorization server will get the associated user record from the database and create a valid JWT with a claim attached that states the user's plan and maybe some other non-personal information. Then once signed it sends it off to the user where the frontend can enable/disable parts of the UI... etc. Hence, if a user logs in on mobile, we can customize the UI based on the same claim sent by the JWT.
My issue is that I don't know if this is a good way to go about it. It seems that everyone I've asked in my circle is split on using JWT or not. Those apposed mostly raise security issues, but, when from what I understand, many of the JWT security pitfalls are well documented and can be avoided just using some commonsense as with any other session/token-based authentication. I'm starting to get analysis paralysis. Please help.
CLASSIFICATION
I would say this is really an API Authorization question, as opposed to an OAuth question:
The role of the Authorization Server and tokens is really just to prove the user's identity
Product specific logic comes after the user logs in and is generally best handled in your app
MY PREFERENCES
Here is how I would handle it:
Save the plan type to your product data when the user signs up
After login, look up the user from the access token
Then look up the user's plan type from your product data
Produce a Claims / Principal object in your API containing both
Enforce business rules based on the plan type claim
I would aim for a Claims object something like this:
class ApiClaims {
// The user id in the access token
userId: string;
// The email
email: string;
// The plan type
planType: string;
// Other claims from the token
// Other claims from product data, eg user roles
}
RESOURCES
If interested in this approach, these blog posts of mine may be of interest:
User Data Management
API Authorization
JWT?
You need some kind of API credential that is sent in HTTPS messages and is web and mobile friendly, so I would use JWTs. You could follow the same pattern with any API credential though.
It depends on what you are trying to protect of course, but JWT bearer tokens are an industry standard. Since you control both the client and the authorization server, you can implement it however you like.
I would look into changing Resource Owner Password Credentials flow to authorization code flow. It will enable you to use social authentication providers like Google or Facebook to sign in users (while still maintaining plan info in your own service). Chances are that people trust those companies more to keep their credentials safe than your company, and it allows you to benefit from any authentication features (MFA) those companies implement.
Also, if you want the clients to read the contents of the token, you should use OpenID Connect id_tokens, as those are guarenteed to be in JWT format.
Cognito is a powerful tool yet it's so hard to utilize it .
Trying to implement my business logic I ended up in some dead ends and I need some help.
My client app is an admin panel where a new admin can register providing a company.
Now there are 2 applications (Contests, Reviews) based on these companies .
So from the adminPanel the admin can create events for both apps through 2 different rest apis
The concept is 1 admin is related to 1 or more companies.I have to map that relationship somehow with Cognito .
Because cognito does pretty much well authentication but not authorization.
In every request not only I have to validate the user by the access token but I also have to see if the user is authorized to do the action based on the company.
For example if a user want to create a Contest event for his company.
I will make a request to Contest Api and I have to authorize that the admin is related to this company
Company entities are used from both apis so I have to expose them in a new api called companies.(If any api wants information about companies it should call the get company/{id})
My consideration is that in order to authorize a user in my apis I have to:
1) validate the access_token .
2) communicate with Cognito to get user informations.
3) call companies api to check if user is authorized to execute actions for this campaign.
So I kind of feeling that it becomes too complex and I need 2 services to authenticate and authorize each request(cognito + company api).
Is there any other way to implement cognito authorization logic without having to use a second api ?
P.S I have already check cognito triggers but they don't cover my needs .For example pre token generation trigger can add claims but it will add them in identity_token not access_token .Also my claims has to be an array of company_ids that an admin is related but claims supports strings and numbers only
Suppose I started with an ASP.NET5 MVC6 webapp based on a default Visual Studio 2015 web application template with individual user accounts and Google+ (FB, LI) authentication enabled.
Then I created two signup pages, one for consumer users and one for professionals. I want the application to create consumer user accounts if users came from consumer signup page. And I want the app to create professional user accounts if users came from the professional signup page.
What should I do to customize the default solution?
pass role parameter to /Accounts/ExternalLogin, then somehow preserve it through OAuth process and fix user creation logic?
same but use cookies to pass role info?
or maybe have 2 copies of external login infrastructure - each responsible for its own account type?
Isn't is a common problem - how to pass additional information to the code responsible for account creation?
What should I do to customize the default solution?
Quite good explanation with examples:
ASP.NET 5 Documentation -> Authorization
I want ... create consumer user accounts ... and ... create professional user accounts...
In my opinion you can use (create) one account type for all (in common Db) and then during registration process you can assign additional properties to this account. You can use Roles or Claims, so this allows you to personalise user experience depends on 'account type' (using Authorisation).
If you just want have only customer/professional accounts, probably Role-Based Authorisation will be simpler to use, however Claims-Based Authorisation is little bit more elastic and will be beneficial in the future.