-
Notifications
You must be signed in to change notification settings - Fork 299
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Client initiated logout / logout propagation to oauth server #2148
Conversation
7fbb41c
to
361ce27
Compare
7116fa2
to
399f11f
Compare
pkg/oauth/server.go
Outdated
@@ -79,8 +79,9 @@ type FrontendConfig struct { | |||
|
|||
// Config is the configuration for the OAuth server. | |||
type Config struct { | |||
Mount string `name:"mount" description:"Path on the server where the OAuth server will be served"` | |||
UI UIConfig `name:"ui"` | |||
DefaultRedirectURI string `name:"default-redirect-uri" description:"The default URI the OAuth server will redirect to after login succeeded"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we leave the "default redirect URI" feature for another PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think then it's best to disable standalone (not client-initiated) logins for the time being. Any other idea?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to keep this PR scoped to one thing, and do other stuff later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I've reintroduced the old login handler which delets the active session, so we can show the current authenticated view of the oauth server again. Also updated the tests accordingly. We will have two logout handlers then in the interim.
399f11f
to
757a353
Compare
05843c1
to
6459389
Compare
84b20c4
to
3891ba3
Compare
Blocking #1422 |
146af81
to
78da59d
Compare
This was actually a bug related to the echo csrf middleware we're using, which spammed the browser with token cookies for all the routes that it was called on and hence mixing up tokens during lookup. This is now fixed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also update doc/content/guides/getting-started/running-the-stack.md
with the logout redirect URIs
CHANGELOG.md
Outdated
@@ -22,6 +22,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 | |||
- `ns.down.data.schedule.attempt` and `ns.down.join.schedule.attempt` events, which are triggered when Network Server attempts to schedule a respective downlink on Gateway Server. | |||
- `ns.down.data.schedule.success` and `ns.down.join.schedule.success` events, which are triggered when Network Server successfully schedules a respective downlink on Gateway Server. | |||
- `ns.down.data.schedule.fail` and `ns.down.join.schedule.fail` events, which are triggered when Network Server fails to schedule a respective downlink on Gateway Server. | |||
- Console logout is now propagated to the OAuth provider. | |||
- This requires a database migration (`ttn-lw-stack is-db migrate`) because of the added columns. | |||
- To set the `logout-redirect-uris` for existing clients, the CLI client can be used, e.g.: `ttn-lw-cli clients update console --redirect-uris "https://localhost:1885/console" --redirect-uris "http://localhost:1885/console"`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a realistic example. Realistic redirect URIs end with /console/oauth/callback
and you're not giving any example for --logout-redirect-uris
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed wrong example. This should just be logout-redirect-uris
instead of redirect-uris
.
pkg/oauth/server.go
Outdated
api.POST("/auth/logout", s.Logout, s.requireLogin) | ||
api.POST("/auth/logout", s.Logout) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't this cause trouble in s.Logout
for users that are not logged in?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed. This is a leftover from before #2148 (comment)
pkg/oauth/user.go
Outdated
if err != nil { | ||
if !errors.IsNotFound(err) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be combined to if err != nil && !errors.IsNotFound(err) {
pkg/oauth/user.go
Outdated
if err = s.store.DeleteAccessToken(ctx, accessTokenID); err != nil { | ||
return err | ||
} | ||
s.removeAuthCookie(c) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't know that the auth cookie corresponds with the session we're deleting. If it doesn't, we may leave a session active while the user thinks it's revoked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't think of any realistic scenario where that would be the case. The user has obtained the access token using this auth cookie (session). Since our official clients tie them together, there should be no corruptions or mixups. So I think this is neglectible. In any case, we still have the old logout handler, so clients can decide for themselves.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed, the logout will now
- delete the access token
- delete the session that was associated with the access token
- delete the session associated with the current auth cookie of the user (if it differs from the sessions stored in the access token)
78da59d
to
fa8339d
Compare
3f91ee9
to
c3ed357
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Go part LGTM with small comment.
pkg/oauth/user.go
Outdated
if err = s.store.DeleteSession(ctx, &at.UserIDs, at.UserSessionID); err != nil { | ||
if !errors.IsNotFound(err) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can combine err != nil && !errors.IsNotFound(err)
c3ed357
to
4fe6c89
Compare
Summary
References #1422
Closes #1702
This PR will enable logout propagation from our official clients, meaning that the console logout will also result in a deletion of the session in the oauth server that was used to create the access token.
Changes
LogoutRedirectURI
field to the clients, used to check the validity of the requested redirect during the client-initiated logoutLogoutURL
config to oauthclient util, used to trigger a logout of the oauth providerNotes for Reviewers
In order to test the setup in dev environment, it is necessary to set two new settings accordingly:
Also the console client needs to be reinitiated:
mage dev:dbStop dev:dbErase dev:dbStart dev:initStack
The flow works like this:
click to enlarge
op_logout_uri
, containing the access token ID, as well as a desiredpost_logout_redirect_uri
access_token_id
query parameter, delete the associated session of the access token and the access token itselfpost_logout_redirect_uri
has been previously registered and redirect back to this URI (if nopost_logout_redirect_uri
was passed, the firstLogoutRedirectURI
of the client will be usedI've kept the frontend changes in this PR to a minimum, so we can focus on the backend changes. I will follow up with a PR that does a proper refactor of the webui after this PR has been merged. This will include removing the login view, refactoring
withAuth
util component, removing unnecessary store logic and removing the landing view of the oauth app.As discussed with @htdvisser, we also plan to to federated logout (meaning logging out all currently authenticated SSO clients associated with the respective oauth session).
This would necessitate adding an
sso
flag to the client model, which will be used to determine what other clients need to be logged out. Should I also integrate this into this PR or use another scoped one?Checklist
README.md
.CHANGELOG.md
.CONTRIBUTING.md
, there are no fixup commits left.