345

Do I need to verify the user for every single page? Absolutely. Not only every page, but every request to a privileged resource, e.g POST request to update data, delete, view, etc, etc. It is not just about viewing the pages, it is about controlling who can do what on your system. It sounds like your entire authentication and permissions system is broken ...


234

The Authorization: <type> <credentials> pattern was introduced by the W3C in HTTP 1.0, and has been reused in many places since. Many web servers support multiple methods of authorization. In those cases sending just the token isn't sufficient. Sites that use the Authorization : Bearer cn389ncoiwuencr format are most likely implementing ...


183

OpenID is a protocol for authentication while OAuth is for authorization. Authentication is about making sure that the guy you are talking to is indeed who he claims to be. Authorization is about deciding what that guy should be allowed to do. In OpenID, authentication is delegated: server A wants to authenticate user U, but U's credentials (e.g. U's name ...


96

Simple Terms OpenID is about verifying a person's identity (authentication). OAuth is about accessing a person's stuff (authorization). OpenID Connect does both. All three let a person give their username/password (or other credential) to a trusted authority instead of to a less trusted app. More Details To understand something, look at its history. ...


83

Has anyone ever thought about doing this? Yes, there was actually a talk about exactly this at defcon 21 (video, slides). Their conclusion was that working with response codes as offensive security can sometimes result in severely slowing down automatic scanners, non-working scanners, and a massive amount of false-positives or false-negatives (it will ...


81

OpenID connect will give you an access token plus an id token. The id token is a JWT and contains information about the authenticated user. It is signed by the identity provider and can be read and verified without accessing the identity provider. In addition, OpenID connect standardizes quite a couple things that oauth2 leaves up to choice. for instance ...


69

According to CISSP study guide , access control include IAAA (Identification, Authentication, Authorization and Accountability). So if you dont care about the rest then you can call Authentication and Authorization as Access control. Where: Identification : User_Name Authentication : User_Name + Password ( in one factor auth , simple case) ...


60

It won't actually slow down an attacker any appreciable amount, but will cause any future developers who work on your platform to be really annoyed at you. It may also cause certain nice features of your HTTP request libraries to not be so nice, as they're operating off of incorrect information. This is a very weak form of security through obscurity. When ...


59

Many people still visit this so here's a very simple diagram to explain it Courtesy Wikipedia


47

Let's walk through how this attack works. The Attack I visit some client's website and start the process of authorizing that client to access some service provider using OAuth The client asks the service provider for permission to request access on my behalf, which is granted I am redirected to the service provider's website, where I would normally enter ...


47

Long before bearer authorization, this header was used for Basic authentication. For interoperability, the use of these headers is governed by W3C norms, so even if you're reading and writing the header, you should follow them. Bearer distinguishes the type of Authorization you're using, so it's important.


46

NOPASSWD doesn't have a major impact on security. Its most obvious effect is to provide protection when the user left his workstation unattended: an attacker with physical access to his workstation can then extract data, perform actions and plant malware with the user's permissions, but not elevate his access to root. This protection is of limited use ...


42

once A gets falsely authenticated as B... On any minimally secure system, this isn't how it happens. From the system's point of view, User B is authenticating himself, not User A. It was not falsely authenticated, it was using the real login and password. It's simple case of Credential Theft. You could harden the system using any form of 2FA, but the system ...


38

The quick answer is yes, as you gathered. But it doesn't need to be the huge job you're thinking of. (The whole security thing might be big, but this is only one part of it). You have far more serious issues than that. Why it matters ANYTHING you create will be hit with attempts to break it. Someone will be curious. Someone will do something you never ...


36

Technically you can store the access token in your database, and use it for API calls until it expires. It might be more trouble than its worth, though. For one thing, as Jonathan notes in his comment above, now you have to worry about securing your database and the data in it - these tokens give access to some fairly privileged information about your users....


35

As Phil stated, you can still use the card using its number (as you would do on-line). Also, some ATM machine won't accept the card if not able to read the magnetic strip. The best thing is to use a credit card: in that case you can block the payment and get a refund.


30

OAuth provides only and should only provides authorization using an access token. OpenID connect is built on OAuth 2 in order to provide user authentication information. However, it will not provide you a more robust implementation than OAuth (since it uses OAuth and add some extra interactions with a OpenID provider). OpenID Connect 1.0 is a simple ...


30

I don't think either of the other previous responses answer the question, which is asking the difference between OpenID Connect and OpenID 2.0. OpenID 2.0 is not OAuth 2.0. OpenID 2.0 and OpenID Connect are very different standards with completely different parameters and response body formats. Both are built on top of OAuth 2.0 by putting additional ...


29

Claims are a method of providing information about a user, and roles are a description of a user by way of which roles they belong. Claims are generally more useful because they can contain arbitrary data -- including role membership information. E.g. whatever is useful for the given application. Claim Based identities are more useful, but tend to be ...


28

You need to check the user permission level for every request (GET, POST, PUT, DELETE). Browsing to a page, like in your case is a GET request. A user shouldn't be able to post a request without permission as well. Now whether you need to add the code on each page of your application depends on your application framework. For example, some frameworks (...


27

Yes, you can. On some places you can find a device called demagnetizer. Just run your card over it (or over a very strong magnet), and the magnetic track will be corrupted and you will only be able to use the chip part of the card.


27

Think about the technical implementation, not about the user or what's painted on the buttons: it's a keypad with 5 buttons. In order to unlock the device, it needs a sequence of those 5 buttons (however many presses of those 5 button it allows). More buttons would make it harder to brute-force the combination. Imagine having only 2 buttons, or imagine ...


27

As Steffen has said you cannot protect the token from users. I'd just like to add a suggestion for a more general scenario of having a "demo" Api. It sounds like your API doesn't have any stored data and just does calculations on input so this may not be a concern for you, but rather than having the demo token point to your real api, you could point it to ...


25

There are two specific cases why you don't want passwordless sudo: This is a defense mechanism against malicious users who gain access to an administrative account. This can either be through exploitation or due to an admin leaving his workstation unattended without locking his session. Having to re-issue the password when using sudo gives impulsive users ...


23

The main advantage of a refresh token is that it is easier to detect if it is compromised. Consider these two scenarios: A single long-lasting auth token is used. A short duration auth token is used, and a long-lasting refresh token periodically requests a new auth token once the previous one has expired. In scenario 1, if the auth token is compromised it ...


20

OpenID and OpenID Connect are both for authentication, not for authorization. The two activities are distinct. OpenID Connect is in fact OAuth (an authorization protocol) which is turned (abused) into an authentication protocol. More explanations in this answer. To some extent you can mix authentication and authorization, but that's a source of confusion. ...


19

Back then, tapes were just binary data on a magnetic film, with no "hidden" channels or out-of-band capabilities. Manufacturers that claimed to make tape-to-tape recording impossible often just made the tape look different, to deter would-be pirates. A regular tape recorder module was usually used to read them, so making "special" tapes couldn't really work. ...


19

As @SteveS said, RBAC is an authorization model whereas claims are a way of providing information about a user. It generalizes the notion of a role. In the past identity servers would simply provide applications the username and the list of roles/groups. Claims generalize this such that any user attribute can be passed on to the consuming application. The ...


17

I will simplify this problem. Cross-Site Request Forgery and Clikjacking attacks are useful because it can force a victim's browser into performing actions against their will. The mention of 10.12. Cross-Site Request Forgery and 10.13. Clickjacking in the OAuth v2 RFC have fundamentally the same concern. If an attacker can force a victim's browser into ...


16

OAuth is an authorisation protocol, providing a way to give authorisation to access a protected resource. A by-product of the authorisation process is that the user is authenticated. Technically, OAuth does not have to give you any information about the user. What it provides is a validation that the user has given authority to the application to access ...


Only top voted, non community-wiki answers of a minimum length are eligible