search

vouch / vouch-proxy

an SSO and OAuth / OIDC login solution for Nginx using the auth_request module
MIT License
2.88k stars 326 forks source link

where should we store data for future retrieval besides the cookie? #111

Open bnfinet opened 5 years ago

bnfinet commented 5 years ago

related to #109

I'd like to document the use cases which we would use and discuss options.

@artagel could you help me to flesh out the thinking here. You've already put quite a bit of good work into #109 but I'm spooked by the lack of iPhone support.

artagel commented 5 years ago
the cookie split is needed no matter what. It'll give a warning, and split cookies if the browse 'does' support it.. with the custom claims support, the claims are an unpredictable size. so, that is use case #1. You can't control, for example, the size of the 'groups' a user is a member of, which is probably the primary use case for claims. the second is that passing down access/idtokens, as requested for downstream auth, would inflate the token size(cookie), right now still under 4096 bytes, but pretty close. so with claims and a combo of the tokens, getting over 4096 bytes is easy. That means storing this in JWT is not correct.
bnfinet commented 5 years ago

how should we support iPhones with custom claims?

Use cases (things we'd like to store and maybe provide to nginx/an app)...

what are we storing and who's going to use it when? Will Vouch Proxy use it to interact with the IdP? Will a VP client (nginx, app) use it?

bnfinet commented 5 years ago

rather than going to an RDBMS, maybe we can provide a mechanism to discover another vouch on your network and then pass data between them using the shared secret.

This seems a bit easier than going full RDBMS and reduces the attack surface.