I need to sum up different ways to authenticate to a REST Webservice. Of course there is the Basic Authentication and i also found the Digest access authentication and the authentication with HMAC.
In RFC2617 there is the Digest access authentication specified as a method, which hash
the username, the password, the given
nonce value, the HTTP method, and the requested URI
and then send this hash with the parameter (but not the password) to the server to authenticate.
Now the Question: Is there a difference / What is the difference between the digest authentication and HMAC?
Using HMAC for authentication, i also have to concat some Strings and hash them...
What are other methodes of autentication? I tried to understand OAuth (RFC6749) but for me it seems to be a Framework which based on other methodes:
Clients in possession of a client password MAY use the HTTP Basic
authentication scheme as defined in [RFC2617] to authenticate with
the authorization server
Related
I have a website where I am using regular HTTP API requests and a websocket authenticated connection for realtime data.
I am using token authentication for API requests, authenticating websocket connection upon connection via header token.
I would however still like to somehow uniquely identify a "session", if a user was using the same token on two machines. Do I save a random string generated upon login along with the authentication token, to uniquely identify a session?
Or did I go about this the wrong way and is token authentication really just not appropriate for my case?
Because token authentication is just so much easier to implement on the frontend, as I am using React.
I'm using Django REST framework JWT library for authentication in my django application. And I thought the whole idea of using JSON Web Token Authentication was NOT having a database trip in every request.
But it still retrieves user's data (which is stored in the token's PAYLOAD) from database per request.
What am I doing wrong?
The webtoken mechanism and the server authentication internals are rather orthogonal.
The web token just allows the holder to say who they are. It is similar to holding a user's username and password, except the token can be revoked without the user having to learn a new password. This authentication technique has nothing to do with whether the server will do a database access.
If you wish to eliminate a DB access during authentication on the server, you can use some sort of authentication caching mechanism like django-cached_authentication_middleware.
I have a dataprovider with a REST service. They said that the authentication goes as follows:
1. Username and Password are passed in the request header
2. If the authentication is successful I get a token which I have to store and use this token to make further requests.
Now I started reading into REST Authentication and just do not understand what kind of authentication they use. I guess I have missunderstood something, so please correct me.
There are three kinds of authentication
1. Basic Authentication (sending username and password base 64 encoded in the header)
2. OpenID (here I send my username and password to a provider to receive a token)
3. OAuth (The caller is identified with a trusted token to let application call another application on a end-user's behalf without requiring the calling application to store the users's username and password)
I cannnot see, where to classify my providers method. 1. I am not sending UserName Password everytime. 2. I do not use a provider, 3. I am not doing application calls and do not use only tokens. Could anyone help me here?
When you send username and password to provider if correct, provider will create a token for this user and this token will be sent to you by provider.
After this, you can use this token in any session and you can check only this token for expiration, you do not have to send username and password everytime.
We have a central RESTful webservices application that exposes data to many different clients (parsers, web applications, touch applications, etc). The clients have different means for authenticating users, some LDAP, others not. Regardless, the RESTful application leaves the authentication of the end-user to the client, and simply authenticates the client making the request. The client will have a username and password in LDAP, along with a list of acceptable IP addresses from which the client can access the RESTful application.
Here is the tricky part: the RESTful application must audit every request with the end-user's username. Furthermore, in certain circumstances (depending on the client) the RESTful application will need the end-user's username and password for accessing a third-party application. So, every request from the client will have authentication credentials for the client itself and the end-user accessing the client.
Here comes the question. Would it be best to put the client's credentials in Basic Auth, and pass the end-user's credentials via an encrypted SALT request parameter? Or, should the client put both sets of credentials in the Basic Auth (i.e. system~username:systempwd~userpwd) and parse them out into two sets of tokens that are then authenticated. Or, another solution that is better than either of these two?
This sounds pretty much like OAuth2's "Resource Owner Password Credentials Grant" - see https://www.rfc-editor.org/rfc/rfc6749#section-4.3. You pass application/client credentials in the Authorization header and client information in the body encoded using x-www-url-encoded. Do that once at the beginning of the session and then depend on a bearer token in the authorization header after that. All of that is described in the RFC. Remember to use SSL/TLS to encrypt the credentials.
I have server with some resources; until now all these resources were requested through a browser by a human user, and the authentication was made with an username/password method, that generates a cookie with a token (to have the session open for some time).
Right now the system requires that other servers make GET requests to this resource server but they have to authenticate to get them. We have been using a list of authorized IPs but having two authentication methods makes the code more complex.
My questions are:
Is there any standard method or pattern to authenticate human users and servers using the same code?
If there is not, are the methods I'm using now the right ones or is there a better / more standard way to accomplish what I need?
Thanks in advance for any suggestion.
I have used a combination of basic authentication and cookies in my web services before. In basic authentication you pass the user name/password encoded in the HTTP header where it looks something like this.
Authorization: Basic QWxhZGluOnNlc2FtIG9wZW4=
The string after the word "Basic" is the encoded user name and password that is separated by a colon. The REST API can grab this information from the HTTP header and perform authentication and authorization. If authentication fails I return an HTTP Unauthorized error and if they are authenticated but are not authorized I return an HTTP Forbidden error to distinguish between failure to authentication versus authorization. If it is a web client and the person is authenticated then I pass the following in the HTTP header with a request.
Authorization: Cookie
This tells the web service to get the cookie from the HTTP request and use it for authorization instead of doing the authentication process over again.
This will allow clients that are not web browsers to use the same techniques. The client can always use basic authentication for every request, or they can use basic authentication on the initial request and maintain cookies thereafter. This technique also works well for Single Page Applications (SPAs) where you do not have a separate login page.
Note: Encoding the user name and password is not good enough security; you still want to use HTTPS/SSL to secure the communications channel.