How nonce and state parameters are stored and transmitted in IdentityServer4?
up vote
0
down vote
favorite
I have read Here about the difference between state and nonce parameters and from what I understood that state parameter is generated by the Authentication server(Identity server) and is used by the client for preventing CSRF attacks whereas nonce parameter is generated by the client and then the Authentication server will include it in the token and client will use it for checking token validity.
My first question is: Is the above flow correct in case of identityServer4 when using implicit grant type or not?
My second question: Where nonce parameter is stored on the user's agent (browser) and how does the client generate and transmit it?
My third question: How client cross-check the state parameter if it's valid or not?
oauth-2.0 identityserver4 openid-connect
add a comment |
up vote
0
down vote
favorite
I have read Here about the difference between state and nonce parameters and from what I understood that state parameter is generated by the Authentication server(Identity server) and is used by the client for preventing CSRF attacks whereas nonce parameter is generated by the client and then the Authentication server will include it in the token and client will use it for checking token validity.
My first question is: Is the above flow correct in case of identityServer4 when using implicit grant type or not?
My second question: Where nonce parameter is stored on the user's agent (browser) and how does the client generate and transmit it?
My third question: How client cross-check the state parameter if it's valid or not?
oauth-2.0 identityserver4 openid-connect
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have read Here about the difference between state and nonce parameters and from what I understood that state parameter is generated by the Authentication server(Identity server) and is used by the client for preventing CSRF attacks whereas nonce parameter is generated by the client and then the Authentication server will include it in the token and client will use it for checking token validity.
My first question is: Is the above flow correct in case of identityServer4 when using implicit grant type or not?
My second question: Where nonce parameter is stored on the user's agent (browser) and how does the client generate and transmit it?
My third question: How client cross-check the state parameter if it's valid or not?
oauth-2.0 identityserver4 openid-connect
I have read Here about the difference between state and nonce parameters and from what I understood that state parameter is generated by the Authentication server(Identity server) and is used by the client for preventing CSRF attacks whereas nonce parameter is generated by the client and then the Authentication server will include it in the token and client will use it for checking token validity.
My first question is: Is the above flow correct in case of identityServer4 when using implicit grant type or not?
My second question: Where nonce parameter is stored on the user's agent (browser) and how does the client generate and transmit it?
My third question: How client cross-check the state parameter if it's valid or not?
oauth-2.0 identityserver4 openid-connect
oauth-2.0 identityserver4 openid-connect
edited Nov 11 at 8:01
asked Nov 11 at 7:55
Simple Code
434218
434218
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
No, both state and nonce are generated by client. Similarly, they are validated by client.
state prevents CSRF attacks. Authorization server will include the state so that authorization response can be validated for original request from client end. Similarly nonce is generated by client. Authorization server simply include it in tokens for validation.
is the above flow correct in case of identityServer4 when using implicit grant type or not?
identityServer4 must support including state and nonce in appropriate responses. I believe it does.
Where nonce parameter is stored on the user's agent (browser) and how does the client generate and transmit it?
This will depend on the client implementation. OIDC protocol provide a guide on nonce implementation
One method to achieve this for Web Server Clients is to store a cryptographically random value as an HttpOnly session cookie and use a cryptographic hash of the value as the nonce parameter
How client cross-check the state parameter if it's valid or not?
When client receives the authorization response, it must verify the precense of state parameter in response URL's query parameters (or fragments). Then it must compare the value with original value it generated.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
No, both state and nonce are generated by client. Similarly, they are validated by client.
state prevents CSRF attacks. Authorization server will include the state so that authorization response can be validated for original request from client end. Similarly nonce is generated by client. Authorization server simply include it in tokens for validation.
is the above flow correct in case of identityServer4 when using implicit grant type or not?
identityServer4 must support including state and nonce in appropriate responses. I believe it does.
Where nonce parameter is stored on the user's agent (browser) and how does the client generate and transmit it?
This will depend on the client implementation. OIDC protocol provide a guide on nonce implementation
One method to achieve this for Web Server Clients is to store a cryptographically random value as an HttpOnly session cookie and use a cryptographic hash of the value as the nonce parameter
How client cross-check the state parameter if it's valid or not?
When client receives the authorization response, it must verify the precense of state parameter in response URL's query parameters (or fragments). Then it must compare the value with original value it generated.
add a comment |
up vote
1
down vote
No, both state and nonce are generated by client. Similarly, they are validated by client.
state prevents CSRF attacks. Authorization server will include the state so that authorization response can be validated for original request from client end. Similarly nonce is generated by client. Authorization server simply include it in tokens for validation.
is the above flow correct in case of identityServer4 when using implicit grant type or not?
identityServer4 must support including state and nonce in appropriate responses. I believe it does.
Where nonce parameter is stored on the user's agent (browser) and how does the client generate and transmit it?
This will depend on the client implementation. OIDC protocol provide a guide on nonce implementation
One method to achieve this for Web Server Clients is to store a cryptographically random value as an HttpOnly session cookie and use a cryptographic hash of the value as the nonce parameter
How client cross-check the state parameter if it's valid or not?
When client receives the authorization response, it must verify the precense of state parameter in response URL's query parameters (or fragments). Then it must compare the value with original value it generated.
add a comment |
up vote
1
down vote
up vote
1
down vote
No, both state and nonce are generated by client. Similarly, they are validated by client.
state prevents CSRF attacks. Authorization server will include the state so that authorization response can be validated for original request from client end. Similarly nonce is generated by client. Authorization server simply include it in tokens for validation.
is the above flow correct in case of identityServer4 when using implicit grant type or not?
identityServer4 must support including state and nonce in appropriate responses. I believe it does.
Where nonce parameter is stored on the user's agent (browser) and how does the client generate and transmit it?
This will depend on the client implementation. OIDC protocol provide a guide on nonce implementation
One method to achieve this for Web Server Clients is to store a cryptographically random value as an HttpOnly session cookie and use a cryptographic hash of the value as the nonce parameter
How client cross-check the state parameter if it's valid or not?
When client receives the authorization response, it must verify the precense of state parameter in response URL's query parameters (or fragments). Then it must compare the value with original value it generated.
No, both state and nonce are generated by client. Similarly, they are validated by client.
state prevents CSRF attacks. Authorization server will include the state so that authorization response can be validated for original request from client end. Similarly nonce is generated by client. Authorization server simply include it in tokens for validation.
is the above flow correct in case of identityServer4 when using implicit grant type or not?
identityServer4 must support including state and nonce in appropriate responses. I believe it does.
Where nonce parameter is stored on the user's agent (browser) and how does the client generate and transmit it?
This will depend on the client implementation. OIDC protocol provide a guide on nonce implementation
One method to achieve this for Web Server Clients is to store a cryptographically random value as an HttpOnly session cookie and use a cryptographic hash of the value as the nonce parameter
How client cross-check the state parameter if it's valid or not?
When client receives the authorization response, it must verify the precense of state parameter in response URL's query parameters (or fragments). Then it must compare the value with original value it generated.
edited Nov 12 at 8:16
answered Nov 12 at 4:10
Kavindu Dodanduwa
5,46611230
5,46611230
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53246830%2fhow-nonce-and-state-parameters-are-stored-and-transmitted-in-identityserver4%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown