EGI-Federation / documentation

Sources to build EGI documentation site.
https://docs.egi.eu/
MIT License
14 stars 48 forks source link

Ssh OIDC tokens #558

Closed marcvs closed 1 year ago

marcvs commented 1 year ago

I found that refresh-token endpoint again...

I think it's a really bad idea to expose that to users.

I've updated the two "alternatives" and added a third one.

"Alternatives" is in "", because I think that the option of spreading refresh tokens to the infrastructure (i.e. https://aai.egi.eu/token) should be the undocumented alternative.

gwarf commented 1 year ago

@enolfc, @vardizzo-lab and @NicolasLiampotis please take into account the point made by Marcus regarding the https://aai.egi.eu/token endpoint.

NicolasLiampotis commented 1 year ago

@enolfc, @vardizzo-lab and @NicolasLiampotis please take into account the point made by Marcus regarding the https://aai.egi.eu/token endpoint.

We can emphasise that tokens should be stored securely like for example GitHub is doing: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token

We could also consider enabling refresh token rotation for the token portal client as described in https://www.rfc-editor.org/rfc/rfc6749#section-10.4. Enabling token rotation will however require users to change their workflow (i.e. they will need to replace their RT after every refresh flow)

marcvs commented 1 year ago

Rotating refresh tokens would allow users to notice if the RT was stolen: If somebody else uses it, the own RT won't work any longer. The problem is, that users need to learn to trigger some kind of incident response in such cases...

NicolasLiampotis commented 1 year ago

The problem is, that users need to learn to trigger some kind of incident response in such cases...

The malicious client’s refresh token (or any subsequently issued refresh tokens) will automatically get revoked when the legitimate client tries to use it so it's not really necessary to trigger an incident response process.

marcvs commented 1 year ago

The problem is, that users need to learn to trigger some kind of incident response in such cases...

The malicious client’s refresh token (or any subsequently issued refresh tokens) will automatically get revoked when the legitimate client tries to use it so it's not really necessary to trigger an incident response process.

Perfect! So: I'm all for refresh-token rotation.

github-actions[bot] commented 1 year ago

Documentation preview deployed!

Available at https://docs.egi.eu/documentation/558

gwarf commented 1 year ago

If one discovers that a token got stollen and used, I guess the security team would really want to be aware and be able to look into this, understanding what happened, the exact impact, if protections could be put in place and so on. We may at least want to document (one the token app page? in docs.egi.eu? in both?) that users should report this (to whom and how).

gwarf commented 1 year ago

@marcvs , can you please rebase the branch? Thanks!

github-actions[bot] commented 1 year ago

Documentation preview deployed!

Available at https://docs.egi.eu/documentation/558

marcvs commented 1 year ago

@marcvs , can you please rebase the branch? Thanks!

Done