In most scenarios a person identifies who they are (authentication/AuthN) via something like a username and password. Afterwards a system would likely evaluate what that validated identity can perform (authorization/AuthZ) via something like AD or LDAP groups.

Does anyone know of systems that evaluates authorization first? For example, before a password is verified or a session (e.g. a cookie) is even provided the system would check the username and see if the claimed identity is even allowed to try and authenticate. If not then it won't even bother with a password check or creation of a cookie/session.

This doesn't really fit the mold of classic authorization. Is there a term for this style of AuthN/AuthZ? I've been Googling all sorts of things to try and find a system, tool, app, term or definition that applies to this use case.

  • You're still describing classic Authentication. I'm not sure where what you're describing is different. – schroeder Oct 23 '14 at 18:22
  • 1
    This is certainly not common, and I expect a bad idea for several reasons. One of them being an unauthenticated user could figure out what resources a particular username has access to. Is there some reason you want to use this pattern? If you ask a separate question about that, people will be more able to help. – paj28 Oct 23 '14 at 18:26
  • @paj28 Simply because the architecture is defined using this model doesn't mean that it need be presented transparently to the end user attempting to authenticate. It's not strictly a poor architectural choice, particularly if your authentication mechanism is relatively expensive and your identification mechanism is relatively cheap. – Xander Oct 23 '14 at 18:28
  • @xander I would disagree, because the method reveals to attackers the identifiers anyway. What good does it do to screen authentication attempts with something you show how to bypass? – Desthro Oct 23 '14 at 19:16
  • Without solid authentication first, you run into other problems. In your example of checking for an authorized user before a password, unauthenticated users could enumerate usernames, backend systems, and their permissions without knowing the password. Assuming there were no other controls. If they need to authenticate with a username and password first, any attacker would need credentials before they could determine anything about the systems behind it. – Paraplastic2 Oct 23 '14 at 19:19

I have seen systems that filter by a list of allowed IP addresses first, so in order to even attempt to use an authentication method you have to be coming from a specified IP address or range. This is similar to what you are describing. But in general, authorization refers to deciding what an authenticated user can do, and so logically comes after the authentication step - except when anonymous access is allowed, of course.

| improve this answer | |
  • We have a system that uses IP filtering, what's funny is I bet we could fool it by forging the IP headers... (The netadmin doesn't like me very much LoL) – Desthro Oct 23 '14 at 19:12
  • Actually this is similar to what I'm curious about, except replace IP with a username. IP can be spoofed and provides no assurance, same as username. Kind of like if I connect from a known malicious IP why should the system check any further. In my example someone is presenting a username that will not be authorized anyway, why even let them in the front door? Key point is also that regardless of a failed check as I've described, a failed password or a failed username "Access denied" (or something) is the only thing the user should see. – ps2005 Oct 24 '14 at 13:09
  • @ps2005 such a name-based pre-auth is a bad idea, as it would allow a user to enumerate the possible authenticate-able user names on the system by observing the different response behaviors. It's why "not a valid name/password combo" is a better error than "no such user on the system." You don't want to provide the attacker an "Oracle" they can use to learn information. – JesseM Jun 23 '17 at 20:36

What you are describing is, in fact, authentication. It is just a more explicit description of the steps involved in authenticating than you might generally see.

Specifically, the steps in the authentication process are identification, and authentication. First you get an identifier (such as a username) and if it is a valid identifier and can be matched in the identity system to a account with an authentication credential, you attempt to authenticate, or match the authentication credential presented (such as a password) to the authentication credential stored for that account.

So, you could call this "Identification and Authentication" if you like, but since both pieces are integral to successful authentication there's really no need to be so explicit.

| improve this answer | |
  • Isn't classic authentication included in this model? First, the username is looked up in a user table, if found, the supplied password is verified. In that perspective, you have implied 'authorization' to log in based on the fact that the credential pair is found in the table of registered users. Am I missing something here? – schroeder Oct 23 '14 at 19:53
  • @schroeder Yes, and no you're not missing anything. My description probably wasn't as clear as it should have been. This is just an explicit definition of the authentication flow, rather than masking it under an opaque model that, for instance would accept a username and password and return an authentication status. Internally that classic model does exactly what this has defined and the OP is suggesting. – Xander Oct 23 '14 at 19:58
  • So, the answer to the OP is simply: "you're describing classic Authentication" ? – schroeder Oct 23 '14 at 20:04
  • @schroeder Yup. I've reworded to (hopefully) clarify. – Xander Oct 23 '14 at 20:09
  • @xander Yes this is an accurate breakdown and I agree that authentication is really two steps "identification" followed by "authentication/credential check". I guess what I'm asking is whether there is ever a model where we have an intermediary between "identification" and "authentication" which is all opaque to the user. Bob has a valid username/PW, but no permissions/roles in a system. Bob identifies himself via a standard login page, but he is denied regardless of his password being correct or incorrect in the form. Would we still consider this all in the realm of authN and not authZ? – ps2005 Oct 24 '14 at 14:41

I guess what is really confusing about this is that it goes against the typical way things are done. But if you want to break it down, let's look at the ways you've proposed.

Authentication then Authorization

This way, a user must prove they are who they say they are (in this case with a username and password, and once they do, the session is authorized to perform certain functions. If the Authentication fails, we know the user is unable to do anything. What's more, is we do not tell them any information about the system other than that their chosen combination of username and password failed.

Authorization then Authentication

I am going to assume for simplicity's sake that you are presenting an identifier, (like a username), in order to check if there are any authorized resources for that identifier. If there is, you ask for a password and Authenticate, and the session continues. If there isn't, you say nope and continue. The problem here is it reveals usernames in use to attackers. Generally speaking usernames are viewed as insecure anyway, but revealing active, non-disabled accounts to an attack can make their job easier. You can build a complete username list by polling through all the options, and make your choices from there.

That's probably why they don't do it that way.

| improve this answer | |
  • I totally understand your scenario, but the difference in the scenario I'm describing is that I don't want the user to know the difference or steps in the validation process. For example... the following scenarios all result in "access denied" at the login page: 1) bad username 2) bad password 3) good username, no groups/permissions (notice I don't care about PW). – ps2005 Oct 24 '14 at 13:14

You are actually bringing about a very interesting point. Instead of just seeing authentication as proving your identity (the fact that you are indeed Bob), see authentication in a broader sense whereby your prove the authenticity of a claim. For instance, you could claim to be 21 years of age, you could claim to be an EU citizen, or you could claim to having a valid driver's license. In all 3 instances, the authorization scenarios would be:

  • ability to buy and consume alcohol in the US
  • ability to enter the EU without a visa
  • ability to drive a car

Note that in these 3 use cases - all about authorization - the end-user's identity is not relevant. Rather, an attribute of the user, a claim if you will, is what matters.

Therefore, to buy alcohol, you do not strictly need to authenticate (i.e. prove that you are Bob). You only need to prove the authenticity of the claim that you are over 21.

As a matter of fact, the UK had this ambitious National Identity Card scheme which was scrapped a few years ago. In that scheme, they had the idea you could show your ID card to a bouncer / bartender and that you could configure the card so that it would only show whether you were over 18 or not but it would hide the rest (e.g. your name, address...) not relevant to the use case.

In conclusion, in order for authorization to work, you need to prove the authenticity of all the claims that you will need for that particular authorization check.

| improve this answer | |
  • 1
    Yes actually this is a similar use case. If I go to a store (USA) and say that I'm 18 yrs old and want to buy beer the clerk won't even bother verifying my identity. If I say I am 21+ they will check my ID, look at my name, picture, etc. I appreciate your example unfortunately I'm too much of a newbie to upvote :( – ps2005 Oct 24 '14 at 14:25

Google for Amazon cookie management. Authentication is only valid for a certain period of time, and once it expires they will not let you perform critical operations without going through it again. That is they first check if your "low quality" identity is authorized to perform an operation, and otherwise ask you to authenticate again to obtain a "strong identity".

I would argue that Windows UAC essentially works in the same vein.

I'm not familiar with a term for such approach, but would myself call it "just in time" or "on the need" authentication.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.