HTTP specification says;
HTTP access authentication is described in "HTTP Authentication:
Basic and Digest Access Authentication" [43]. If a request is
authenticated and a realm specified, the same credentials SHOULD
be valid for all other requests within this realm (assuming that
the authentication scheme itself does not require otherwise, such
as credentials that vary according to a challenge value or using
synchronized clocks).
I don't really understand what this means, but here is my scenario is there anything against HTTP specs here? I use Java Rest service
Client sends username:password using HTTP Authorization header using HTTP Basic
Server sends back a token
Now client sends a custom authorization token instead of password for further requests still in the HTTP authorization header still using HTTP Basic username:token
Now this does not feel right since what I am really doing with the auth token is NOT an actual HTTP Basic authorization. Also usage of the very same header is inconsistent between requests.
But on the other hand I do not want create yet another custom header for the token exchange. Because its hard to base64 encode them with test tools when you use a custom header. And still inconsistent headers between requests.
Note: these requests refers to different endpoints
What do you advice?
If you do that, since you are using the same headers, aren't you going to need server side logic to differentiate when the login is the actual login, as opposed to your token? At the end of the day, HTTP Authorization is already a token (only a simple encoded version of the username/password string), so in all cases you are receiving a token, now you have to decode it, decide if it's one of your session tokens, or if it's a username/password, and therefore check against two sources of "good tokens".
I would advice against this, but not because you're breaking standards, it just feels convoluted.
Why do you need to change username/password to a token on the first place? Are you redirecting to an endpoint where you no longer require HTTP Basic Auth?
Related
I'm building a REST service and right and have run into a problem. Right now the functionality is this: a user can post their username and password and if it's correct I return a JWT token for them.
What do I need to do in order to make a client use this token when they request something from a protected endpoint? I'm new to web in general and I don't know where to go from here.
First, you have to save the JWT somewhere. In a browser, the best options are in cookies or local storage (see where to store your jwts for an example on how).
Second, you need to pass the JWT back to the server with your next request. You will have to retrieve the JWT from wherever you stored it and include it in the request. How you do this depends on where the server expects your JWT to go and what framework you use for making requests. For example, if your JWT goes in one of the request headers, here is an example for setting request headers with a jquery ajax request.
There are two URL, suppose URL1 and URL2. URL1 can be used only by provide the proper credentials. I have completed this part by writing the code for simple authentication. However to connect to URL2, I have to maintain the session from URL1. I cannot figure this part out. It is showing response code as Forbidden!
, I have to maintain the session from URL1.
It is not likely since on any website, the session is maintained only if the first connexion is maintainted. HTTP is stateless
When you authenticate on a website, generally, you receive a token in the HTTP response (generally in the headers). After being authenticated, for each request, you must re-send that token in your HTTP requests (generally in the headers) otherwise the server considers you as unauthenticated.
So, to solve your problem, you should analyse what the server give you in headers response when it authenticates you successfully.
If you can test your scenario with a browser which owns tools to intercept request/response content, you should easily find the token information sent in the request.
Where can I find the basic HTTP authentication credentials (username and password) in the incoming request to my server?
Is it somewhere in the Request object, or is there some other way to get them?
thanks
When a browser sends HTTP Basic authentication info, it basically sends an HTTP Header named Authorization
with a value of
Basic somethinghere.
The part after Basic is really just Base64.encode("${username}:${password}")
Check out this basic description of the procedure.
Here is a SO answer that describes how you can easily obtain the authentication credentials from the HTTP Header.
When a html page makes a call to a rest webservice, how can the service credentials be sent in the request?
The username and pwd needed by the service can be sent in the request itself by using (usename:pwd#service.com) notation, but that would not be wise sending in the creds in the request itself.
Any other ways to solve this problem?
If it uses BASIC authentication, it is sent along the request as a header (in clear). Have a look at:
http://en.wikipedia.org/wiki/Basic_access_authentication
This can be hardened by using a secure protocol (https), with which you encode your request (basic authentication included).
http://en.wikipedia.org/wiki/HTTP_Secure
This requires additional configuration on the server-side
I'm trying to extract information from an URL using my Java code. But the URL has a pop-up authentication scheme. How would I know the authentication scheme used? I have the credentials for it.
A browser typically shows an authentication "popup" when the server responds to an HTTP request with a "401 Unauthorized" response message. The response header includes a "WWW-Authentication" header which tells you the authentication scheme to use (among other things).
There are various ways to deal with this in a Java application, depending on how you are attempting to fetch the web resource associated with the URL. For instance, if you are using HttpUrlConnection, you can extract the "WWW-Authentication" header, parse it, and extract the authentication scheme.
Normally the authentication is based on HTTP. There are several techniques to use (HTTP basic authentication Kerberos NTLM and so on) Each of this technologies applies additional information into HTTP header. So the authentification is not URL based but HTTP Header based.
Please give us more information about your problem, to help you