Stream: implementers
Topic: OAuth State Parameter
Shahzeb Jadoon (Sep 19 2019 at 15:35):
Hello Everyone,
State(a random string for CSRF) in OAuth2 must be unique per user request/session?
If it is per session I'm using web API whose definition said it should be stateless(Server has no clue about client state) then how can i achieve that?
Michael Donnelly (Sep 19 2019 at 15:42):
The state token I'm aware of is per session as part of getting the auth code.
1. You pass a state token to the EHR when you request an auth code.
2. The EHR returns your state token with your auth code
How does that mismatch with the API you're using?
Shahzeb Jadoon (Sep 19 2019 at 17:36):
Michael Donnelly question is not about mismatching .
Question 1: When an app causes the browser to navigate the browser to the EHR’s authorization URL, state already present there. But if same user send again a request in this case state will be change or same?
Question 2: And if a user refresh authorization URL then state will be same or change?
Josh Mandel (Sep 19 2019 at 17:41):
The requesting app sets the state when it begins any given OAuth interaction -- so it (the app) is in charge of determining whether it's the same or different. But from a security perspective, a best practice is for the app to make these state values unguessable and unique.
Michael Donnelly (Sep 19 2019 at 18:24):
When you say "request" are you only talking about the request to the authorization URL?
Josh Mandel (Sep 19 2019 at 18:58):
That's right.
Michael Donnelly (Sep 19 2019 at 19:40):
Heh. I know you are; I'm asking @Shahzeb Jadoon
Shahzeb Jadoon (Sep 20 2019 at 12:02):
Yes Michael Donnelly.
Shahzeb Jadoon (Sep 20 2019 at 12:14):
I am confused, when a user get authorization code on behalf of state. If a request comes from same state again, should we allow that user as new login or reject the request ?
Josh Mandel (Sep 20 2019 at 13:31):
Enforcing unique states is not the responsibility of a server --
Josh Mandel (Sep 20 2019 at 13:31):
It is a best practice for the client developer. A server just passes the client-supplied states through the interaction, from the authorized step through the redirect.
Ali Haider (Sep 20 2019 at 13:38):
@Josh Mandel
I think he may be asking that, he should maintain that particular state or every request will have unique State parameter. If yes then how will he know to which request he will send response.
Josh Mandel (Sep 20 2019 at 13:48):
Basically the requirement is that the server will mint an authorization code that it associates with the request's state value, so that it can return the state in the final access token response. You could accomplish that in a stateless (for the server!) way by creating the authorization code as an encrypted and authenticated blob that internally includes this state value. But one of the requirements for the server is to reject token requests with authorization codes that a client attempts to use more than once-- so you at least need to keep a cache of recently used authorization codes with a time-to-live that is greater than your authorization code usage window
(I was answering without enough sleep; please ignore ;-))
Michael Donnelly (Sep 20 2019 at 14:42):
I am confused, when a user get authorization code on behalf of state. If a request comes from same state again, should we allow that user as new login or reject the request ?
A server need not persist the state beyond that single interaction. The only thing the server needs to do with the state is return it with the auth code. It never looks at it, thinks about it, or retains it beyond that.
Michael Donnelly (Sep 20 2019 at 14:42):
It would be insecure for a client to reuse a state token, but the server doesn't enforce that.
Shahzeb Jadoon (Sep 21 2019 at 11:15):
Josh Mandel what you meant by that ? Have you got enough sleep now :grinning_face_with_smiling_eyes: ?
Last updated: Apr 12 2022 at 19:14 UTC
