Dynamic state in OAuth2
Yes they are using OIDC, the implementation is working except for that little detail
Yes in most cases it's, but in this one all sites using their authentication method must have dynamic state (it's a governmental provider) to be certificated
Can you explain more about what this dynamic state requirement is?
In the their docs says:
Step 1
The integrator must protect the security of its citizens by preventing request forgery attacks, for this the first step is to create a unique session token, which maintains the state between the citizen and the integrated application.
You must then match this unique session token with the authentication response returned by the service. Thus, both, our service and the integrated service can ensure that it is the user who is making the request and that it is not a malicious attacker. This type of attack is called Cross-Site Request Forgery (CSRF).
A good option to implement this unique session token is to generate a random string of 30 or more characters through some library or to generate a hash through a secret.
Step 2
Make the HTTP request (...)
State: The same unique session token that was indicated in Step 1 must go in this parameter.
I see. So this sounds like the standard oauth flow. We actually have trouble with this because our API is stateless.
Maybe you can create a GitHub issue for this?
Sure I will So what is used to create the state in this moment?
I see so, wouldn't be so hard to change to a dynamic state... I'll test it, and create the issue as well
The hard part is getting Appwrite to maintain the state and validate it
I'm planing to work in the changes now and I see where is the problem, I don't see any other solution than store the state in the database 🤔
related issue: https://github.com/appwrite/appwrite/issues/5520
I'm thinking something to avoid store the state in the database:
- Generate a token with the appwrite secret and send it
- The token is returned by the OAuth2 entity
- Validate the token with the appwrite secret
If there is no problem with the validation, means no CSRF attak is made
What you think?
How would step 3 actually work? How would Appwrite validate it?
You generate a payload and sign it (with the secret), and send it when it returns you validate it with the same secret, the payload can have the success and failed url too, and also this token can have an expiration time, you check the signature and the expiration time, that way you only need the secret
Currently if you close your session and log in again the session will be create again without ask for any credentials
btw, i thing this state stuff is unrelated to your problem
What would be that issue related to? 🤔
it's just some configuration in your provider
I'm not sure but maybe, in this case is relate, I'll keep investigating, I'm not 100% familiar with their implementation
who's the provider?
Chilean Government
no the authorization provider. what product are they using?
also, you can try passing prompt=login in the first request to the auth provider
what you mean with product?
they're probably using some sort of identity management product. do you have any documentation from them that you can share?
Sure can I send to you in a PM?
