is the logout request only for openid?
I can request the login, consent and presumably the logout per oauth2/auth.
this model indicates the necessary data, needed for a logout to be successfull
is the session_id to be set at login, does hydra set one at random or is another variable responsible in case it is missing, such as the login_verifier?
tl;dr
how would one go about and logging out a client which has an access token?
I could not find any resources except for openid.
An Access Token (proof of authorization) is not the same thing as a “login session”
(which is what we have OpenID Connect for).
From the docs:
" A logout request may be initiated by the OpenID Provider (OP - you ) or by the Relying Party (RP - the OAuth2 Client):
The RP-initiated flow needs an id_token_hint and may optionally define state and post_logout_redirect_uri .
About the session_id:
“LoginSessionID is the login session ID. If the user-agent reuses a login session (via cookie / remember flag) this ID will remain the same. If the user-agent did not have an existing authentication session (e.g. remember is false) this will be a new random value. This value is used as the “sid” parameter in the ID Token and in OIDC Front-/Back- channel logout. It’s value can generally be used to associate consecutive login requests by a certain user.”
Let me know if that helped!
atm i don’t bother about openID and just try to get the basics right.
I know that a logout won’t invalidate an access_token.
but there is a logout endpoint for “/oauth2/auth/requests/logout”, which appears to be for the relaying party (client). correct me if I’m wrong
I can’t find any model conforming to the requirements as pointed out by the documentation thus my question. but I had the same problem with the login flow and deduced the needed params from the link in the consent-node, which isn’t practical. i can’t do the same for the logout because I can’t get logout to work properly. (“unable to fetch the requested resource”)
maybe there is documentation or code that I missed you could point me to?
EDIT:
the login request (containing the Sid) results if sent only in a response containing the csrf and a 302 to a location containing the challenge. but not the random Sid which has purposedly been set automatically
I don’t really understand the question, what are you trying to do, what are you expecting to happen, and what happens instead?
there is the request to get the login challenge, the url containing the following:
[
“client_id”: “auth-code-client”,
“nonce”: nonce,
“redirect_uri”: “http://127.0.0.1:5555/callback”,
“response_type”: “code”,
“scope”: “openid offline”,
“state”: state
]
I want to acquire equal information to succeed at the logout endpoint at “/oauth2/auth/requests/logout”
ps: the “nonce” and the “state” are placeholders for the random string
So you want to see, for example, the ClientID associated with the logout request?
I guess I am expressing myself in an unclear fashion.
I have no clue how the information itself stands out especially in my formulation, so I will try again.
my goal is to get the logout_challenge. which parameters do I have to encode into the url? and which endpoint do I have to address? is it documented? can someone point me to the source, where it is implemented?
EDIT:
I am looking for the logout equivalent of this:
okay I may have sounded more aggressive than I like to admit.
the logout flow is well documented. my mistake was disregarding the endpoint “/oauth2/sessions” for it not being documented in its own section.
Dont worry about it!
Implementing this on your own can often be frustrating, because it is quite complex, even with documentation.
hackerman is unfortunately busy at the moment, but I am certain he will get back to your issue, when there is some free time.
By the way, I was just looking through older issues on ORY Hydra.
Is this related to your problem?
Add oAuth2Client to logoutRequest similar to loginRequest. #1483
well I don’t like the approach of using a separate client_id for each user. I would rather use the subject
field to differentiate users while the client_id could represent the service serving to the user. something like “mobile_app”.
I suppose there is no issue of subjects from the same client identifying as another.
Does this adress your problem?
Ok so your problem is resolved then?
Yes, please don’t use client_ids as a substitute for users!