Skip to content
Back
Self Hosted

Dynamic state in OAuth2

View on Discord

Votes

0

Replies

24

Participants

Unknown

Messages

25

GuilleOriginal post

Moderator

Yes they are using OIDC, the implementation is working except for that little detail

Guille

Moderator

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

Drake

Admin

Can you explain more about what this dynamic state requirement is?

Guille

Moderator

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.
Drake

Admin

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?

Guille

Moderator

Sure I will
So what is used to create the state in this moment?

Guille

Moderator

I see so, wouldn't be so hard to change to a dynamic state... I'll test it, and create the issue as well

Drake

Admin

The hard part is getting Appwrite to maintain the state and validate it

Guille

Moderator

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 🤔

Guille

Moderator

I'm thinking something to avoid store the state in the database:

  1. Generate a token with the appwrite secret and send it
  2. The token is returned by the OAuth2 entity
  3. Validate the token with the appwrite secret

If there is no problem with the validation, means no CSRF attak is made

What you think?

Drake

Admin

How would step 3 actually work? How would Appwrite validate it?

Guille

Moderator

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

Drake

Admin

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

Guille

Moderator

What would be that issue related to? 🤔

Drake

Admin

it's just some configuration in your provider

Guille

Moderator

I'm not sure but maybe, in this case is relate, I'll keep investigating, I'm not 100% familiar with their implementation

Drake

Admin

who's the provider?

Guille

Moderator

Chilean Government

Drake

Admin

no the authorization provider. what product are they using?

Drake

Admin

also, you can try passing prompt=login in the first request to the auth provider

Guille

Moderator

what you mean with product?

Drake

Admin

they're probably using some sort of identity management product. do you have any documentation from them that you can share?

Guille

Moderator

Sure can I send to you in a PM?

Join the discussion

Reply to this thread by joining our Discord.

Reply on Discord

Need support?_

Join DiscordGet premium support