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

Implementation: Operation level security #2624

Closed
timotheeguerin opened this issue Nov 1, 2023 · 0 comments · Fixed by #2901
Closed

Implementation: Operation level security #2624

timotheeguerin opened this issue Nov 1, 2023 · 0 comments · Fixed by #2901
Milestone

Comments

@timotheeguerin
Copy link
Member

timotheeguerin commented Nov 1, 2023

Design #1210 Proposal https://gist.github.com/timotheeguerin/56690786e61a436710dd647de9febc0f

alias MyOAuth2 = OAuth2<{
  type: OAuth2FlowType.implicit;
  authorizationUrl: "https://api.example.com/oauth2/authorize";
  refreshUrl: "https://api.example.com/oauth2/refresh";
}>;
@useAuth(MyOAuth2)
@authScopes(MyOAuth2, "read", "write", "delete")
namespace MyService;

// Have to use X-API-KEY header auth.
@authScopes(MyOAuth2, "read")
op list(): FileInfo[];

@authScopes(MyOAuth2, "read")
op read(): FileInfo;

@authScopes(MyOAuth2, "write")
op upload();

@authScopes(MyOAuth2, "delete")
op delete();


@markcowl markcowl added this to the Backlog milestone Nov 8, 2023
susliko added a commit to susliko/typespec that referenced this issue Feb 8, 2024
susliko added a commit to susliko/typespec that referenced this issue Feb 8, 2024
susliko added a commit to susliko/typespec that referenced this issue Feb 9, 2024
susliko added a commit to susliko/typespec that referenced this issue Feb 12, 2024
susliko added a commit to susliko/typespec that referenced this issue Feb 13, 2024
susliko added a commit to susliko/typespec that referenced this issue Feb 15, 2024
susliko added a commit to susliko/typespec that referenced this issue Feb 22, 2024
susliko added a commit to susliko/typespec that referenced this issue Feb 26, 2024
Resolves microsoft#2624

Major changes:
- `@useAuth` can now be used both at interface and operation levels
- OAuth2 scopes can be overriden at operation level
susliko added a commit to susliko/typespec that referenced this issue Feb 26, 2024
Resolves microsoft#2624

Major changes:
- `@useAuth` can now be used both at interface and operation levels
- OAuth2 scopes can be overriden at operation level
susliko added a commit to susliko/typespec that referenced this issue Feb 27, 2024
Resolves microsoft#2624

Major changes:
- `@useAuth` can now be used both at interface and operation levels
- OAuth2 scopes can be overriden at operation level
susliko added a commit to susliko/typespec that referenced this issue Feb 27, 2024
Resolves microsoft#2624

Major changes:
- `@useAuth` can now be used both at interface and operation levels
- OAuth2 scopes can be overriden at operation level
timotheeguerin added a commit that referenced this issue Feb 27, 2024
Hi! 🖖🏻 
This PR resolves #2624 by implementing the [design
doc](https://gist.github.com/timotheeguerin/56690786e61a436710dd647de9febc0f),
but in its initial form:
- `@useAuth` can now be applied not only to service namespace, but to
interfaces and operations as well. Its arguments override all
authentication, which was set for enclosing scopes.
- OAuth2 scopes can now be set at operation level (though, the code
doing this in OpenAPI emitter is a bit clunky).
- New `NoAuth` authentication option allows to declare optional
authentication (`NoAuth | AnyOtherAuth`) or override authentication to
none in nested scopes.

This implementation does not introduce new `@authScopes` decorator as
design doc comments suggest, and here's why:

1. It does not compose well with `@useAuth` at operation level. For
example
```
...
@useAuth(BasicAuth)
@authScopes(MyOauth2, ["read"])
op gogo(): void
```
Should that be equivalent to `BasicAuth | MyOauth2`, or to `[BasicAuth,
MyOauth2]`?

2. Introducing new decorator would increase complexity, but (imho) it
would not reduce the amount of boilerplate:
```
alias MyOAuth2 = OAuth2Auth<{ ... }>;

@useAuth(MyOAuth2)
@authAcopes(MyOauth2, ["read"])
@service
namepsace Foo;
```
vs
```
model MyOAuth2Flow<T extends string[]>  {  ...  };
alias MyOauth2<T extends string[]> = Oauth2Auth<[MyOauth2Flow[T]]>

@useAuth(MyOAuth2<["read"]>)
@service
namepsace Foo
```

I would be happy to hear any feedback and apply suggested changes.

And thanks for a convenient development setup and thorough test
coverage!

---------

Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>
markcowl pushed a commit to markcowl/cadl that referenced this issue Mar 8, 2024
Hi! 🖖🏻 
This PR resolves microsoft#2624 by implementing the [design
doc](https://gist.github.com/timotheeguerin/56690786e61a436710dd647de9febc0f),
but in its initial form:
- `@useAuth` can now be applied not only to service namespace, but to
interfaces and operations as well. Its arguments override all
authentication, which was set for enclosing scopes.
- OAuth2 scopes can now be set at operation level (though, the code
doing this in OpenAPI emitter is a bit clunky).
- New `NoAuth` authentication option allows to declare optional
authentication (`NoAuth | AnyOtherAuth`) or override authentication to
none in nested scopes.

This implementation does not introduce new `@authScopes` decorator as
design doc comments suggest, and here's why:

1. It does not compose well with `@useAuth` at operation level. For
example
```
...
@useAuth(BasicAuth)
@authScopes(MyOauth2, ["read"])
op gogo(): void
```
Should that be equivalent to `BasicAuth | MyOauth2`, or to `[BasicAuth,
MyOauth2]`?

2. Introducing new decorator would increase complexity, but (imho) it
would not reduce the amount of boilerplate:
```
alias MyOAuth2 = OAuth2Auth<{ ... }>;

@useAuth(MyOAuth2)
@authAcopes(MyOauth2, ["read"])
@service
namepsace Foo;
```
vs
```
model MyOAuth2Flow<T extends string[]>  {  ...  };
alias MyOauth2<T extends string[]> = Oauth2Auth<[MyOauth2Flow[T]]>

@useAuth(MyOAuth2<["read"]>)
@service
namepsace Foo
```

I would be happy to hear any feedback and apply suggested changes.

And thanks for a convenient development setup and thorough test
coverage!

---------

Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants