Skip to content
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

Store additional metadata with sessions #2091

Closed
4 of 6 tasks
joekrill opened this issue Dec 30, 2021 · 2 comments
Closed
4 of 6 tasks

Store additional metadata with sessions #2091

joekrill opened this issue Dec 30, 2021 · 2 comments
Labels
feat New feature or request.
Milestone

Comments

@joekrill
Copy link
Contributor

Preflight checklist

Describe your problem

There isn't a great way to distinguish between multiple sessions beyond the date it was created (and perhaps the authentication method). Once #655 (Admin/Selfservice session management #655 ) is implemented, we should be able to show user's a list of their sessions and allow them to revoke individual sessions. Most implementations will show additional information about a session, like the IP address and user agent/browser that was used. But Kratos currently does not store this information alongside each session.

For example this is what Gmail shows me when I view a list of active sessions:
Screen Shot 2021-12-30 at 12 45 12 PM

Describe your ideal solution

Ideally when a session is created (or extended?) at least the IP address and User Agent would be captured and stored. The IP address could add some complications because of proxies and request forwarding.

Perhaps there is just a metadata field that can be populated using jsonnet? Maybe a hook could allow customizing what sort of metadata is stored?

It would also be ideal if we could provide a physical location. Something like the IP2Location databases could be utilized. I'm not sure if this is something that would be out of scope for Kratos, though. It could certainly be handled outside of that.

Workarounds or alternatives

It might be possible to use a web hook that then stores this information externally, since a web hook can include the request headers. But it doesn't seem that you can ascertain a particular session ID from the payload of a webhook -- only the current identity is available? So I'm not sure this is a real great workaround.

Version

0.8.2-alpha.1

Additional Context

No response

@joekrill joekrill added the feat New feature or request. label Dec 30, 2021
@aeneasr
Copy link
Member

aeneasr commented Dec 31, 2021

Thank you for this great write-up! I think all the points made are very valid. From an implementation standpoint, I would really like for us to have a standardized way and avoid JsonNet and other dynamic configurations. Those often make systems quite slow (JsonNet is really not that fast unfortunately).

IMO we should keep track of devices and locations. So user agents, IPs, and (if possible) the geo2ip locations. And I think we should try and track all IPs associated with a session, not just the one which was used to sign in! So we might need an array of devices and locations, when they were observed, etc. So maybe something along the lines of:

type IP {
  IP net.IP
  Location ...
  SeenAt []time.Time
}

type Device struct {
  IPs []IP
  UserAgent []string
  SeenAt []time.Time
}

Or something similar! I think we should first try to nail what metadata we can and want to collect, and then how to track changes over time. Once we have that, we can easily push a PR for this :)

@kelkarajay
Copy link
Contributor

Discussion about the implementation in progress is here - #2715 (comment)

@aeneasr aeneasr closed this as completed in 82bc9ce Oct 4, 2022
peturgeorgievv pushed a commit to senteca/kratos-fork that referenced this issue Jun 30, 2023
Closes ory#2091
See https://github.com/ory-corp/cloud/issues/3011

Co-authored-by: hackerman <3372410+aeneasr@users.noreply.github.com>
Co-authored-by: Patrik <zepatrik@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat New feature or request.
Projects
None yet
Development

No branches or pull requests

3 participants