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

Log schema stability guarantees #16

Open
exFalso opened this issue Aug 5, 2024 · 0 comments
Open

Log schema stability guarantees #16

exFalso opened this issue Aug 5, 2024 · 0 comments

Comments

@exFalso
Copy link

exFalso commented Aug 5, 2024

Describe the problem you'd like to have solved

TLDR: We would like to understand the API stability guarantees that Auth0 provides when it comes to the log entry format.

We are currently implementing an authentication scheme that leverages the security log to protect users from a compromised Auth0 management account. To do this we need to parse specific log entries and correlate them with data found in tokens. This means that the security log API will become part of our "availability hot path" where API breakages would directly affect our users' ability to log in.

Describe the ideal solution

An ideal solution would be a description of the guarantees. In particular, when a breaking change does happen, what is the process of rolling it out? Can we get some kind of notification? How long would it take between the notification and the release of the new format?

Alternatives and current work-arounds

We could make the parsing "lax" and try to create a "degraded security" authentication scheme. Breaking change happens => our software is not able to prove the integrity of the login flow => but it can continue to function with restricted functionality, until we implement the handling of the new format. However, this requires considerable extra engineering effort and degraded UX.

Additional context

We are using Auth0 and confidential computing enclaves to create a "strong authentication" scheme that's resistant to compromise of our own stack. In this threat model Auth0 is trusted as the IdP root, but our tenant/management plane is explicitly not trusted.

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