As a preface I'd like to claim I have some understanding of how the HTTP-supported authentication is supposed to work according to RFC 7235.
I am specifically interested to know how a client is supposed to know, after authenticating, which URIs on the server it is expected to provide same authorization (through the Authorization header) bearer for? Furthermore, is there any provision by HTTP to assist client in determining which Authorization headers it (the client) may have available (through whatever means it acquires them -- "login" form/dialog etc), would go with which realm(s)?
A realm doesn't seem to be specified in the form of an URI or even a regular expression of an URI, it's a value the interpretation of which appears to be left to the HTTP client application. Of note, a "Protection Space (Realm)" is defined, quoting:
A protection space is defined by the canonical root URI (the scheme and authority components of the effective request URI (see Section 5.5 of RFC7230) of the server being accessed, in combination with the realm value if present.
The above is all well and good, but it doesn't facilitate client mapping realms to URIs that may require authorization.
Say my Web server returns a response with status code 401 and the WWW-Authenticate: Bearer realm="The hangout" header line, for a request with a given URI, let's say /foobar. That makes it obvious that subsequent requests to the particular URI must include Authorization header line corresponding to solved challenge (as the client authenticates the user). No problem there. But what about e.g. requests with URI(s) that have the same pathname - those starting with /foobar/ -- is there an implication here that the same Authorization value is expected for these as well? What about entirely unrelated URI pathnames [on the same server]?
It would seem beneficial for the kind of authorization negotiation HTTP already does, to somehow relate or facilitate said relation of realms to URIs. But maybe I am missing something very obvious. Does HTTP do something along of what I am describing? Does it facilitate it in any way, at least, beyond leaving it entirely to the application? How would one realistically let the client determine which authorization bearer to send for which requests? Must it always get a 401 and a challenge response first, before knowing for sure requests to the particular URI and only said URI, must include related authorization bearer?
HTTP is a stateless protocol that deals with a request-response pair. The protocol does not deal with any information that would describe the concept of a "page", "site", "application", etc. Even though it deals with hypermedia, the protocol itself doesn't go beyond the concrete request. This means that you won't get any information from the protocol itself about any other paths under the same domain that are in the same authentication realm. This is left to the documentation of APIs or websites.
It seems to me that your research is centered on one type of authentication process that we call basic auth, know they are some other ways to authenticate a user and that they might suits your needs better as basic auth is kinda old as you can see on that RFC you linked.
To my understanding, the principle behind basic auth is to have a simple process based on challenges. When your client asks for a resource and that resource is protected by authentication, the server responds with a challenge : 401 Unauthorized with a header WWW-authenticate: Basic realm="some realm". The client then know the resource is restricted and depending on the realm, knows if it can have access (or asks the user for credentials for that realm), and try to access with a basic auth header : Authorization: Basic viFWGrwehryfviehtNRBRGWrwGERThRGE. You then repeat that process every time you need a resource.
HTTP and basic auth don't implement any sort of deeper and more complex system for authentication like you're searching for. It's one of the simplest system as its name implies and has not a lot more to offer. I'd even add that it's one of the riskier way to authenticate a system (even using SSL cert and cert pinning) as the client must send credentials for every single authenticated resource request.
In case you want to search other ways to authenticate requests, here are some :
OAuth (2.0) (most secured and complex)
Bearer (JWT or session tokens)
API keys
Related
As described in RFC 4559, the Negotiate mechanism may take several requests to complete a GSSAPI context. I cannot understand from the RFC what mechanism is used to associate those requests with one another, however. To take the example described in section 5 of the the RFC:
1:
C: GET dir/index.html
2:
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Negotiate
3:
C: GET dir/index.html
C: Authorization: Negotiate a87421000492aa874209af8bc028
4:
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356
5:
C: GET dir/index.html
C: Authorization: Negotiate 89a8742aa8729a8b028
This is clear to me up until step 5. Assuming there are potentially many clients doing authentication at the same time, how does server know that the Authorization header in step 5 is the response to the data from step 4? I can't see any mention of session cookies or anything, and while I'm not an expert on GSSAPI, I don't think there's anything inherent in the GSSAPI data that can be used to associate it with an authentication session.
So what's the deal? :)
State is maintained using the TCP connection. RFC-4559 doesn't spell this out directly, likely because it would make the author feel dirty. But they elude as much in section 6 when discussing "Session-Based-Authentication" when proxies are involved. This requirement is also "called-out" in the last paragraph of RFC-7230 section 2.3 when discussing how HTTP is supposed to be a stateless protocol:
Some non-standard HTTP extensions (e.g., [RFC4559]) have been known to violate this requirement, resulting in security and interoperability problems
There is even more ambiguity with another requirement in the last paragraph in Section 6:
When using the SPNEGO HTTP authentication facility with client-supplied data such as PUT and POST, the authentication should be complete between the client and server before sending the user data. The return status from the gss_init_security_context will indicate that the security context is complete. At this point, the data can be sent to the server.
So the server should remember the authentication state after the context is successfully completed (and sent the client the 200 with the last token), to let-in one last request containing the actual payload?
Your confusion is justified.
From RFC 7235
5.1.2. Considerations for New Authentication Schemes
There are certain aspects of the HTTP Authentication Framework that
put constraints on how new authentication schemes can work:
o HTTP authentication is presumed to be stateless: all of the
information necessary to authenticate a request MUST be provided
in the request, rather than be dependent on the server remembering
prior requests. Authentication based on, or bound to, the
underlying connection is outside the scope of this specification
and inherently flawed unless steps are taken to ensure that the
connection cannot be used by any party other than the
authenticated user (see Section 2.3 of [RFC7230]).
Which is how I remembered it, but I wanted to make sure. So each request that the user sends includes all the necessary credentials. The server itself knows nothing about what the authentication is. It just asks whether the credentials are valid, and if the answer is yes, go on with the request.
I'm implementing a REST API that also provides functionality for authenticating users. Authentication requires an user to send a POST request with the following data in the body:
{
"userOrEmail": "spook",
"passowrd": "Test1234"
}
If the username and password match, the user gets back a token from the server, while if they don't, the server returns 401 Unauthorized, with the following header:
WWW-Authenticate: Credentials realm="http://localhost:9000/auth/users/credentials"
Is that header acceptable? realm contains the location where the user can try to authenticate again.
It appears to be acceptable, but maybe not optimal except under very specific conditions. From RFC1945:
The realm value (case-sensitive), in combination with the canonical root URL of the server being accessed, defines the protection space. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, which may have additional semantics specific to the authentication scheme.
So, you can, but I might be paranoid about multiple applications using the same authentication and inadvertently cross-authenticating if they were to share the same realm name. Better would be to isolate the realm by application, just to be on the safe side.
No, it's not acceptable.
a) There is no authentication scheme called "credentials".
b) The purpose of the "realm" parameter is different.
I'm creating a RESTful service to provide data to a web application. I have two related questions about this.
1. How to deal with unauthorized requests?
I'm intending to respond to requests with the following codes:
Is the resource open and found? 200 OK
Do you need to be authenticated to access the resources? 401 Unauthorized
Don't you have access to a category of resources? 403 Forbidden
Do you have access to a category of resources, but not to this specific resource? 404 Not Found to prevent people from getting to know the existance of a resource they do not have access to.
Doesn't the resource exist? 404 Not Found
Is this a recommended way for a RESTful service to behave?
2. What WWW-Authenticate header should 401 responses supply?
I read on Wikipedia (probably not the most accurate resource, but it works for me) that a 401 response must include a WWW-Authenticate header, however upon further searching I couldn't really find any resource that stated what this value means and what it should be.
I found several SO questions and forum topics about this header and they all seem to be about OAuth, suggest against using 401 status codes or say you can just make something up.
What is the correct value this header should contain?
To answer your questions:
How to deal with unauthorized requests?
The way you described it is pretty much the recommended way for a RESTful service. As far as I can see there is absolutely nothing wrong with that.
What WWW-Authenticate header should 401 responses supply?
In general the WWW-Authenticate header tells the client what kind of authentication the server will accept. If the client makes an unauthorized request, which means he is sending a request with a missing or invalid Authorization header, the server will use WWW-Authenticate to tell the client what authentication scheme he will accept (i.e. Basic, Digest or OAuth) and for what realm.
Imagine it like some kind of identification question or challenge on the part of the server, i.e. something like "Who are you?" or "Prove who you are by providing credentials in the following way!".
For Example: WWW-Authenticate: Basic realm="My App"
Here the server tells the client that he uses an authentication scheme named Basic. The realm is nothing more than some string that identifies a protected space on the server.
Based on my research (googling) i decided to send: Newauth realm="use login token".
The website http://greenbytes.de/tech/tc/httpauth/#unknown has test cases for different auth methods and i haven't found anything which describes 'get auth token' and therefore i think it is a 'Newauth'.
Also important for me: This doesn't create a login prompt on client side.
I have a web service REST API on a secure ASP.NET website which requires a login to work. What is the most secure way to request the username/password programatically? (just adding a ?username=me&password=mysecret to the URL doesn't seem all that secure to me (even though this is a HTTPS connection).
There are several ways to achieve what you need:
[WRONG WAY] One could pass the username and password along with the query string. In theory there is nothing wrong with this practice, but such a URL (http://example.com?username=me&password=mysecret) is usually cached by browsers, proxies, etc and thus leverage a potential risk that someone else can access to your protected data by using these stored data.
[GOOD WAY] In order to remove "almost all" risks related to caching abilities of browsers, proxies, etc. and moreover in order to use standard features of the HTTP protocol, you have to deal with the special HTTP Authorization header.
The HTTP Authorization header :
If you are using HTTP S connections, then you can use the Basic Access Authentication method.
The Authorization header is constructed as follows:
Username and password are combined into a string "username:password".
The resulting string literal is then encoded using Base64.
The authorization method and a space i.e. "Basic " is then put before the encoded string.
For example, if the user agent uses 'Aladdin' as the username and 'open sesame' as the password then the header is formed as follows:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
If you are using HTTP connections, then you should use the Digest Access Authentication method. Because it's more complicated and useless with HTTPS connections, I let you read more about it if you want (here maybe).
I need to authenticate a client when he sends a request to an API. The client has an API-token and I was thinking about using the standard Authorization header for sending the token to the server.
Normally this header is used for Basic and Digest authentication. But I don't know if I'm allowed to customize the value of this header and use a custom authentication scheme, e.g:
Authorization: Token 1af538baa9045a84c0e889f672baf83ff24
Would you recommend this or not? Or is there a better approach for sending the token?
You can create your own custom auth schemas that use the Authorization: header - for example, this is how OAuth works.
As a general rule, if servers or proxies don't understand the values of standard headers, they will leave them alone and ignore them. It is creating your own header keys that can often produce unexpected results - many proxies will strip headers with names they don't recognise.
Having said that, it is possibly a better idea to use cookies to transmit the token, rather than the Authorization: header, for the simple reason that cookies were explicitly designed to carry custom values, whereas the specification for HTTP's built in auth methods does not really say either way - if you want to see exactly what it does say, have a look here.
The other point about this is that many HTTP client libraries have built-in support for Digest and Basic auth but may make life more difficult when trying to set a raw value in the header field, whereas they will all provide easy support for cookies and will allow more or less any value within them.
In the case of CROSS ORIGIN request read this:
I faced this situation and at first I chose to use the Authorization Header and later removed it after facing the following issue.
Authorization Header is considered a custom header. So if a cross-domain request is made with the Autorization Header set, the browser first sends a preflight request. A preflight request is an HTTP request by the OPTIONS method, this request strips all the parameters from the request. Your server needs to respond with Access-Control-Allow-Headers Header having the value of your custom header (Authorization header).
So for each request the client (browser) sends, an additional HTTP request(OPTIONS) was being sent by the browser. This deteriorated the performance of my API.
You should check if adding this degrades your performance. As a workaround I am sending tokens in http parameters, which I know is not the best way of doing it but I couldn't compromise with the performance.
This is a bit dated but there may be others looking for answers to the same question. You should think about what protection spaces make sense for your APIs. For example, you may want to identify and authenticate client application access to your APIs to restrict their use to known, registered client applications. In this case, you can use the Basic authentication scheme with the client identifier as the user-id and client shared secret as the password. You don't need proprietary authentication schemes just clearly identify the one(s) to be used by clients for each protection space. I prefer only one for each protection space but the HTTP standards allow both multiple authentication schemes on each WWW-Authenticate header response and multiple WWW-Authenticate headers in each response; this will be confusing for API clients which options to use. Be consistent and clear then your APIs will be used.
I would recommend not to use HTTP authentication with custom scheme names. If you feel that you have something of generic use, you can define a new scheme, though. See http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-latest.html#rfc.section.2.3 for details.
Kindly try below on postman :-
In header section example work for me..
Authorization : JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyIkX18iOnsic3RyaWN0TW9kZSI6dHJ1ZSwiZ2V0dGVycyI6e30sIndhc1BvcHVsYXRlZCI6ZmFsc2UsImFjdGl2ZVBhdGhzIjp7InBhdGhzIjp7InBhc3N3b3JkIjoiaW5pdCIsImVtYWlsIjoiaW5pdCIsIl9fdiI6ImluaXQiLCJfaWQiOiJpbml0In0sInN0YXRlcyI6eyJpZ25vcmUiOnt9LCJkZWZhdWx0Ijp7fSwiaW5pdCI6eyJfX3YiOnRydWUsInBhc3N3b3JkIjp0cnVlLCJlbWFpbCI6dHJ1ZSwiX2lkIjp0cnVlfSwibW9kaWZ5Ijp7fSwicmVxdWlyZSI6e319LCJzdGF0ZU5hbWVzIjpbInJlcXVpcmUiLCJtb2RpZnkiLCJpbml0IiwiZGVmYXVsdCIsImlnbm9yZSJdfSwiZW1pdHRlciI6eyJkb21haW4iOm51bGwsIl9ldmVudHMiOnt9LCJfZXZlbnRzQ291bnQiOjAsIl9tYXhMaXN0ZW5lcnMiOjB9fSwiaXNOZXciOmZhbHNlLCJfZG9jIjp7Il9fdiI6MCwicGFzc3dvcmQiOiIkMmEkMTAkdTAybWNnWHFjWVQvdE41MlkzZ2l3dVROd3ZMWW9ZTlFXejlUcThyaDIwR09IMlhHY3haZWUiLCJlbWFpbCI6Im1hZGFuLmRhbGUxQGdtYWlsLmNvbSIsIl9pZCI6IjU5MjEzYzYyYWM2ODZlMGMyNzI2MjgzMiJ9LCJfcHJlcyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbbnVsbCxudWxsLG51bGxdLCIkX19vcmlnaW5hbF92YWxpZGF0ZSI6W251bGxdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltudWxsXX0sIl9wb3N0cyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbXSwiJF9fb3JpZ2luYWxfdmFsaWRhdGUiOltdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltdfSwiaWF0IjoxNDk1MzUwNzA5LCJleHAiOjE0OTUzNjA3ODl9.BkyB0LjKB4FIsCtnM5FcpcBLvKed_j7rCCxZddwiYnU