Ory
Fleeting- see,
ory Cookie-based security model
- Référence externe : https://www.ory.sh/docs/security-model
Ory Identities implements special browser APIs which use additional security measures such as anti-CSRF cookies
[…]
uncommon approach that might require a shift in thinking
[…]
don’t have to worry about refreshing tokens or deciding whether to store them in localStorage or document.cookies
[…]
devote all your focus and time to developing great software for your users, while Ory takes care of the security by giving you the best-in-class protection from all common browser attack vectors, such as Cross-site scripting (XSS) or Cross-site request forgery (CSRF).
To manage HTTP cookies, Ory APIs must be exposed on the same domain as your application. If you don’t fulfill this requirement, HTTP Cookies are ignored by the browser, which prevents the Ory Identities from functioning properly.
HTTP cookies are a central part of the unique security model in Ory.
[…]
HTTP cookies to store session states and protect against attack vectors such as CSRF
Ory issues HTTP cookies with the following flags for the highest level of security:
- secure: The cookie is only sent over HTTPS connection to protect against man-in-the-middle attacks.
- httpOnly: The cookie is not available to JavaScript code to protect against XSS.
- sameSite=Strict: The cookie can only be requested from the same origin to protect against CSRF attacks.
kratos: the authentication layer
hydra: the OIDC layer
-
Référence externe : https://www.ory.sh/docs/hydra/concepts/openid-connect-oidc
-
Référence externe : https://www.ory.sh/docs/hydra/concepts/oauth2
-
Référence externe : https://www.ory.sh/docs/hydra/concepts/before-oauth2 Do you need OAuth2? | Ory
OAuth2 and OpenID Connect are so-called delegation protocols which aren’t concerned with user registration, password recovery, changing a password or email address and so on
Actually, OAuth2 and OpenID Connect don’t even specify how your users sign in
they only establish that you need a method for users to sign in.
common misconception is that access and refresh tokens represent a user session. They don’t.
Access and refresh tokens allow developers you don’t know to do things in your application in the name of your users over a prolonged period of time
ever wondered why, when signing into Google/Facebook/Twitter/…
- you don’t see a screen asking you to grant permission (“Do you want to allow … to access your …?”)?
- their mobile app doesn’t open a browser window or use an embedded WebView?
- our browser doesn’t perform tons of redirects?
The answer is quite simple - they don’t use OAuth2 or OpenID Connect for login and session management in first-party scenarios
Without OAuth 2.0, a resource owner who wants to share resources in their account with a third party would have to share their credentials with that third party.
With OAuth, clients can request access to resources on a server, and the owner of these resources can grant the requested access together with dedicated credentials.
OpenID Connect is a protocol built on top of OAuth 2.0 for just authentication (instead of authorizing access to resources).
Audience of an Access Token refers to the Resource Servers that this token is intended for.
primary use case for OpenID Connect is to solve “Login with <Google|Facebook|Hydra>” flows.
— https://www.ory.sh/docs/hydra/concepts/openid-connect-oidc
ID Token’s purpose is to authenticate the End-User at the OAuth2 Client Application
— https://www.ory.sh/docs/hydra/concepts/openid-connect-oidc
it’s just a “certificate”.
— https://www.ory.sh/docs/hydra/concepts/openid-connect-oidc
webhooks to add custom claims to tokens
-
Référence externe : https://www.ory.sh/docs/hydra/guides/claims-at-refresh
allows updating id_token and access_token when a registered client sends a token request. The flow is realized by calling the defined token hook endpoint which returns updated data.
keto: the permission layer
It claims to implement zanzibar.