I'm learning about OpenID connect and OAuth2.0 and i think there is something missing, what the client will do after receiving the ID token from the authorization server?
Ok it now has a JWT that contains information about the user, but when the user wants to send a request to the client to do whatever he wants to do, he should attach a token with his request, right? so, when the client will generate this token? as far as i know, if a server uses HTTP as its protocol, it can't send data to the user if the user didn't issue a request, so it shouldn't be able to send that token without a request from the user.
Did i miss something?
I tried to search about this stuff, and I didn't find anything useful.
Ok it now has a JWT that contains information about the user, but when
the user wants to send a request to the client to do whatever he wants
to do, he should attach a token with his request, right?
Should say "but when the client wants to send a request to the server ..."
if a server uses HTTP as its protocol, it can't send data to the user
if the user didn't issue a request, so it shouldn't be able to send
that token without a request from the user.
The token will have been provided to the client during sign-on process.
To summarise the process:
Client enters credentials (e.g. username and password) and sends those to a login endpoint.
The login server will generate a JWT and return to client.
Client receives a JWT and caches it locally at the client end ready to be sent to the server on subsequent requests.
On all subsequent requests to the server the client will attach the cached JWT in the authorization headers of the http request.
The server will validate the token to ensure client is authenticated.
Related
I have read a lot of posts/comments saying that CSRF token can be used for improving security for a Web application or an API but I cannot find information how CSRF token is implemented.
I assume on the server side one can store CSRF tokens in a memory cache, SQL server, etc I assume the client sends the token back in a POST request, in the header but how does the server sends a token to a client securely and where does the client store the token (some posts say don't store the token in the session cookie and some say don't store it in a hidden field but do not state the alternative)? Furthermore, does the server generate different tokens during a session (ie. a new token per request)?
I'm learning about Basic Authentication and Jwt Authentication with Java and Spring and I want to ask you if basic authentication is a session based authentication?
I know that in a session based authentication, when the client log in, a sessionId is stored in cookie on the client browser and after that when the client make another request, the server compares the sessionId with the data stored in the memory of the server. And also I want to ask you how is the sessionId sent from client browser to server? Is it sent in the header like a token or how?
And the last question is how the server validate the Jwt token? I know that in case of session authentication, the sessionId sent from client is compared with the data from the memory of the server. But what's happen in case of Jwt authentication? The token is sent with the header and I know that the server validate it and there is no data in the memory of the server. Then how the server compares the token? Any feedback will be apreciated! Thank you!
if basic authentication is a session based authentication?
I know that in a session based authentication
well then why do you ask?
Actually - basic authentication means, that the user credentials(username and password) are sent in the Authorization http header
Authorization: Basic base64(username:password)
The server may or may not use a session cookie. Session cookie may be used with other authentication means or even without any authentication
how is the sessionId sent from client browser to server?
As a session cookie A session cookie is sent as an http header which browser treats as session-persistent
And the last question is how the server validate the Jwt token?
The JWT token should be signed. Note the token has usually 3 parts
header.body.signature
the header specifies a signature type (an asymmetric key or shared secret) and the signature is authenticated (signed or hmac-ed) header and content.
So - the server must validate the issuer, expiration and the signature.
So the server (service provider) doesn't need know the client's identity upfront. The service provider needs to know the issuer's (authentication service which issues the jwt token) public key or shared secret key.
After the jwt validation the service can assume the caller's identity based on the information in the jwt token.
why Jwt is more recommended?
It depends in the use case. (everything has its pros and cons)
I'd recommend using jwt in a distributed and/or microservice architecture. The service doesn't need to access the credentials or to authenticate the user.
In the basic authentication we need to send the username and password for every request.
In the session authentication we will send username and password at initial request. Then from server response we get the session id which stores in browser and gonna use that for requests.
In the token authentication we will send username and password at initial request. Then from server response we get the token and gonna use that for requests.
hope u got it!!
The image below depicts basic HTTP authentication. The client requests /family resource and it is asked to identify itself. It does and now it can access the /family. The client then also asks for /family/photos/kids resource which is in the family realm.
The client already identified itself for /family resource, but not also for /family/photos/kids. They are in the same realm, but the server doesn't know that the same client issued a request. Or does it? How does the server know that this particular client is also allowed to access /family/photos/kids on subsequent request? Is the password and username send on every request after the user has authenticated? Is the client asked for via pop-up for every request he/she makes? Are cookies set upon first authentication?
Basic authentication requires a header sent by client. No cookies or server session
When the client requests a resource, sends the Authorization header
GET /family
Authorization: Basic token
Where token is base64(username: password). Username followed by ':' and password encoded in base 64
If you are requesting a protected resourced from your browser for example a GET request, and you do not provide the header, the browser shows the autenticathion form and remember it for subsequent requests in the same domain
Let me quote HTTP 1.1 RFC specification from www.w3.org.
10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a
WWW-Authenticate header field (section 14.47) containing a challenge
applicable to the requested resource. The client MAY repeat the
request with a suitable Authorization header field (section 14.8).
14.8 Authorization
A user agent that wishes to authenticate itself with a server usually, but not necessarily, after receiving a 401
response does so by including an Authorization request-header field
with the request. The Authorization field value consists of
credentials containing the authentication information of the user
agent for the realm of the resource being requested.
Why the credentials intended to prove user identity (Authentication) passed in Authorization header?
You can see it like this. The server says to the client "Please authenticate before accessing this resource" and sends information on how the client should do the authentication (WWW-Authenticate). The client is responsible for authenticating and then sends proof of that authentication to the server (Authorization).
The Basic authentication scheme messes things up because the authorization is a username and password, that is, you authorize by authenticating against the server itself (showing you know a user and password).
Nevertheless other schemes allow the client to authenticate with a third-party and only send a proof of the authentication to the server. The server can verify the authorization and may not know who the client is (although it typically does).
Note This is only a rationalization. I don't mean to say this was the motive behind the chosen names.
One possibility is that it is talking about the authorization from the user's perspective, not the server's.
There are actually two authorizations going on:
The user authorizing the client to act on their behalf.
The server authorizing the user to access its resources.
If we assume the header is named after 1) then we have:
The user authorized the client to act on their behalf. That authorization goes in the Authorization header. The server then used the user's authorization of the client to authenticate the user (confirm the client is acting on behalf of the user). Now it knows who the user is, it will then do its own separate checks for 2), to see if the user is authorized to perform the request.
Which status code would you use in this scenario, assuming you're using a token based authentication:
The client has a token and makes a request to the server.
The token expired and the server sends a 401 Unauthorized.
The client sends the refresh token.
The token is invalid and the server responds with XXX?
The use case would be an application, that automatically catches 401's and makes a request with the refresh token. If the server would respond with a 401 if this token is not valid, the client would try to request a new access token with the refresh token forever. But it should tell the client, that it should re-authenticate with its credentials (e.g. email and password).
I was just wondering which status code would be the best fit in this scenario, as the spec says in case of a 403 Forbidden "authorization will not help".
I would not make access and refresh tokens interchangeable: Use Access-Tokens to access protected resources and use Refresh-Token to fetch new Access-Token from a special end-point. OpenID Connect works this way.
You would have one HTTP request more but HTTP codes would not be a problem and, in my opinion, you would get a cleaner code.