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

[extension] Use dedicated audience for dust api. Add scopes verification #8719

Merged
merged 9 commits into from
Nov 19, 2024

Conversation

tdraier
Copy link
Contributor

@tdraier tdraier commented Nov 18, 2024

Description

This introduces the usage of a custom auth0 API for our public api. The audience is set in an env var , DUST_API_AUDIENCE which should be https://dust-dev.tt/api/v1 in development or https://dust.tt/api/v1 in production.

This API defines scopes in auth0 configuration, that will need to be extended, for checking particular endpoints in the api. All scopes used by the app are set - we'll have to add/define other ones in another PR.

The scopes required by the app must be specified when requesting authorization, which will result in displaying a consent screen :

Screenshot 2024-11-18 at 16 07 01

(This consent screen can be skipped for 1st party apps , i.e. our own apps registered in our auth0 tenant, but must be shown for 3rd party apps)

The 2 wrappers withPublicAPIAuthentication and withAuth0TokenAuthentication are extended to support new option "resourceName" that can be used to create the scope.

Scope are only checked against oauth tokens . sk- keys are considered system and do not include any scope (no scope check).

Risk

For oauth users, some routes now require scope.

Deploy Plan

  • Set up prod API on auth0
  • Set DUST_API_AUDIENCE env vars
  • Deploy front

@tdraier tdraier requested review from PopDaph and flvndvd November 18, 2024 15:13
Copy link

github-actions bot commented Nov 18, 2024

Warnings
⚠️

Files in **/api/v1/ have been modified and the PR has the documentation-ack label.
Don't forget to run npm run docs and use the Deploy OpenAPI Docs Github action to update https://docs.dust.tt/reference.

Generated by 🚫 dangerJS against 9490661

@tdraier tdraier requested a review from Fraggle November 18, 2024 15:15
front/lib/api/auth0.ts Outdated Show resolved Hide resolved
front/lib/api/auth0.ts Outdated Show resolved Hide resolved
front/lib/api/auth0.ts Outdated Show resolved Hide resolved
@tdraier tdraier requested a review from flvndvd November 19, 2024 06:48
Copy link
Contributor

@flvndvd flvndvd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, left one last comment.

requiredScopes?: Record<string, string>
) {
if (requiredScopes && req.method && requiredScopes[req.method]) {
return [requiredScopes[req.method]];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to return an array here? If it's expected maybe it should be getRequiredScopes and let's define the return type.

Copy link
Contributor

@Fraggle Fraggle Nov 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: are they all required ?
Usually it's one of them, not all of them as scopes are granular.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If one of them, i would rename as getAllowedScopes()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right, I don't think we need an array for now

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i was expecting all required, but yes could be an array of "at least one", that's probably more useful. For now i think we can stick with one single value

@Fraggle
Copy link
Contributor

Fraggle commented Nov 19, 2024

Love that !
Quick question: did you define the scopes in auth0 dev env as well ? (saw that you did)
Seems like the scopes values are not type checked, can you add it if not ?

@Fraggle
Copy link
Contributor

Fraggle commented Nov 19, 2024

nit: from the screenshot, the user facing description of the scopes in the consent screen are not amazing, can you update ? (saw that you did)

@Fraggle
Copy link
Contributor

Fraggle commented Nov 19, 2024

@tdraier but I'm wondering if you are not going to break the raycast extension.

Copy link
Contributor

@Fraggle Fraggle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm putting a request change because I'm worried that it breaks the raycast extension.
Let's talk before merging.

return resolve(new Err(Error("Invalid token payload.")));
}

if (requiredScopes) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't you need to check if the audience matches too ?

(and maybe skip the checks if not the right audience, as a temporary measure not to break the raycast extension)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The audience is checked along with the expiration and issuer by jwt.verify

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it's checked for consistency / signature but not for a specific value (may be wrong)

My point here is twofold:

  • do the checks on scope only if the audience match the expected audience
  • TEMPORARY, otherwise, let it go thru (so the raycast extension still works)

After the extension is updated, we'll wait a few days and then remove the temporary passthru.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

( jwt.verify checks that the audience matches the one passed in parameter )


export function getRequiredScope(
req: NextApiRequest,
requiredScopes?: Record<string, string>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imho, the typing of that arg should be more strict (POST|GET|PATCH|DELETE: scopes that exists)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

req.method is not typed (it's a string), so in theory I can receive anything in here

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...but in practice we know what we use (and we can extends if needed)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i was afraid of the typings, but ok, done 😛

if (requiredScopes) {
const availableScopes = decoded.scope.split(" ");
if (
requiredScopes.some((scope) => !availableScopes.includes(scope))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see my comment required vs allowed.

@tdraier
Copy link
Contributor Author

tdraier commented Nov 19, 2024

@tdraier but I'm wondering if you are not going to break the raycast extension.

this definitely require changes in raycast extension

@Fraggle
Copy link
Contributor

Fraggle commented Nov 19, 2024

@tdraier but I'm wondering if you are not going to break the raycast extension.

this definitely require changes in raycast extension

I can do it swiftly but there is a delay for them to approve, and for users to update. We need an intermediary step where the extension still work.

@Fraggle Fraggle self-requested a review November 19, 2024 09:16
Copy link
Contributor

@Fraggle Fraggle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM !

@tdraier tdraier added the documentation-ack Used to acknowledge that documentation is up-to-date with this PR label Nov 19, 2024
@tdraier tdraier merged commit 217bc8b into main Nov 19, 2024
6 checks passed
@tdraier tdraier deleted the oauth-api branch November 19, 2024 09:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation-ack Used to acknowledge that documentation is up-to-date with this PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants