89
votes
Accepted
Role vs Permission Based Access Control
(1) What is so "bad" about checking Roles for access control? What
benefits are gained by checking for permissions instead?
At the moment of checking, the calling code only needs to know "does user ...
27
votes
Role vs Permission Based Access Control
In response to your first question, the biggest issue with checking that a user has a role rather than a specific permission, is that permissions can be held by multiple roles. As an example to this, ...
25
votes
Accepted
Should I split my API by user type?
No you shouldn't use level of access as part of the URI.
There is already a standard way to separate API by user access, and that's with authorization. All users should access the same endpoints, and ...
22
votes
How to design role based access control?
I would not use or implement RBAC. Instead I would use ABAC. Let me explain...
RBAC or role-based access control is about user management and role assignment. In RBAC, you get to say that Alice is a ...
21
votes
Accepted
How to design role based access control?
Your design seems pretty close to me. Just a couple suggestions.
users - People who will use the system. Here I have usernames and passwords.
Fine
roles - Collection of roles that users can ...
21
votes
Accepted
Where to place an API key: a custom HTTP header VS the Authorization header with a custom scheme
Be consistent
Some may say this is unnecessary (and not too long ago I would have agreed) but these days, with so many auth protocols, if we use the Authorization header to pass an API key, worth ...
20
votes
Accepted
Authorization and authentication system for microservices and consumers
Authentication and authorization are always good topics
I will try to explain to you how we deal with authorizations in the current multi-tenant service that I am working. The authentication and ...
18
votes
Accepted
Difference between 'aud' and 'iss' in jwt
These are intended for scenarios where you have a token issuing authority that is not the same as the application that is the intended recipient.
This may not be different for your application.
But ...
16
votes
Implementing DDD: users and permissions
I have run into the same questioning and am posting the answer I have come up with because it might give some additional vision on the topic, even though the discussion took place a while ago (still ...
15
votes
Accepted
Is it bad practice to store a user's email address in a JWT?
Yes, it is bad practice and a security problem.
Email addresses are PII (personally identifiable information). Like all other PII, email addresses should never be stored unencrypted at rest; doing so ...
14
votes
Is it bad practice to store a user's email address in a JWT?
The short answer is no. There should not be any problem because email is a valid and registered public claim.
I have a user DB where each user's unique ID is their email ...
Well, there's a ...
14
votes
Synonym for "Authorization"?
Using another word for "Authorization" or "Authentication" isn't helpful for writing documentation. Even though they're obscure, these two are already the most common words for those things, and any ...
12
votes
Implementing DDD: users and permissions
Authentication and Authorisation is a bad example for DDD.
Neither of these things are part of a Domain unless your company creates security products.
The Business or domain requirement is, or ...
12
votes
Accepted
Dealing with permissions for the list of resource
To summarize my understanding of your question, you want: a centralized service that would handle all permissions and ideally this service would omit using the database directly without big ...
11
votes
Accepted
cookie vs. session vs jwt
Cookies: in their early version, a text file with a unique client Id
an all the other information needed about the client (e. g. roles)
Cookies are tuples key-value originally addressed to retain ...
10
votes
Accepted
Should I store my user claims in the JWT token?
I store identifier claims only (userid, etc.) (encrypted) in my jwt.
Then when I get the token on the server (API) I can do a lookup server side (db,redis, or local network api call) and retrieve all ...
7
votes
User authorization with microservices
I would use a central, unified authentication system and have separate permissions/stats for each microservice (sort of like how I can't yet upvote on this stack exchange site but I can in stack ...
7
votes
Accepted
Authorization checks without littering them in code
What you are asking for has a name, a model, and even implementations (open-source libraries as well as commercial products).
Externalized Authorization Management
What you are looking for is called ...
7
votes
cookie vs. session vs jwt
Cookies: in their early version, a text file with a unique client Id an all the other information needed about the client (e. g. roles)
Your definition of cookie doesn't really describe what they do. ...
7
votes
Accepted
Implementing DDD: users and permissions
It's sometimes difficult to distinguish between real access control rules and domain invariants borderlining on access control.
Especially, rules that depend on data only available far into the ...
6
votes
Accepted
Auth options for distributed systems
There are many reasons not to use basic authentication scheme to protect Web API services.
In order to use the service, the client needs to keep the password somewhere in clear text to send it along ...
6
votes
Accepted
Microservices and authorization
No, you are not using tokens correctly.
The idea is that you have an Auth service which issues tokens and Resource services which can validate the token and read the claims it contains. So the rather ...
6
votes
Accepted
OAuth2 overkill for small business
The problem with basic authentication over SSL is it depends on passing reversably-encoded user credentials with every API request. This is a security issue because unless you intend to make the user ...
6
votes
OAuth2 overkill for small business
You are right, OAuth2 is overkill in this specific case and despite the comments, it will add unnecessary complexity to the whole project. That being said, remember that OAuth2 is not an ...
6
votes
Accepted
Authentication and authorization - front-end vs back-end dilemma
The backend person might have omitted their valid justifications
Back-end person claims that front-end should to have two calls. First to authenticate user (login process) with JWT response only ...
6
votes
Should user and service-to-service authentications be separate?
There is no "ideal" here - it all depends on what you need.
While focused on more modern technology, the core of your question is no different from ASP.Net's classic impersionation feature ...
6
votes
Accepted
What's the difference between policy vs permission based access control?
The classic example of policy based auth, which I'm sure you have seen if you have googled, is a alcohol selling app, which in (normal countries) would read:
Allow user if user.age > 18
this is ...
5
votes
User authorization with microservices
Each microservice should not have to do its own authentication, but it does need to do its own authorization.
Source
And this makes perfect sense. I'm assuming there is no doubt about central ...
5
votes
Should it be a claim, a role or a policy?
Essentially you are describing a mapping of Role to Permission.
I think this is pretty much covered by the standard [Authorize(Role=xxx)] on your controller actions, where the implied permission is ...
5
votes
should you have separate application service methods for different roles
No, you should not. You should handle the logic for different roles within the method. In your example there will be one exposed method:
pubic void completeDelivery(User user) { ... }
There are a ...
Only top scored, non community-wiki answers of a minimum length are eligible
Related Tags
authorization × 165authentication × 64
security × 30
microservices × 24
rest × 23
architecture × 16
api × 16
oauth2 × 15
permissions × 14
jwt × 13
access-control × 13
design × 12
api-design × 10
c# × 9
.net × 7
domain-driven-design × 7
session × 7
roles × 7
oauth × 6
database-design × 5
asp.net × 5
asp.net-mvc × 5
users × 5
web-applications × 4
mvc × 4