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

Binding the auth session to the device #129

Open
janakamarasena opened this issue Nov 13, 2024 · 0 comments
Open

Binding the auth session to the device #129

janakamarasena opened this issue Nov 13, 2024 · 0 comments

Comments

@janakamarasena
Copy link

janakamarasena commented Nov 13, 2024

Under section 5.3.1. “Auth Session” spec mentions;

To mitigate the risk of session hijacking, the 'auth_session' MUST be
bound to the device, and the authorization server MUST reject an
'auth_session' if it is presented from a different device than the
one it was bound to.

I completely agree on the need to mitigate the risk of session hijacking. However, in the current text, although it's not directly mentioned here, it will require the AS to have a proof of possession mechanism in place as pointed in Section 9 "Security Considerations". This can be a major barrier to implement this specification as the AS should also implement another specification. There can be different ways the implementation can solve this problem without needing proof of possession. For example if the auth_session is only transmitted between the AS and the client then it will be protected with TLS in transit and the client and AS can use independent mechanisms to protect the auth_session at rest. Since this specification applies only to first party applications the implementers will have full control over how the client and the AS protects the data, and therefore can make sure adequate protection is in place for the auth_session. Due to this I think it is better to change wording from mandating to a recommendation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant