Once #1060 is done, decide the configuration setup. The above workflow will be slightly different in terms of its configuration set up compared to making a normal application work with the workflow, especially configuring the redirections. Setting up the workflow is quite flexible in normal applications, and that may not be the case when it comes to API Gateway, especially the redirections. Note that user is not writing any code using Rib or injecting logic within a component. This would imply most of the heavy lifting is done within the OpenAPI spec.
The bare minimum that we expect is the following:https://swagger.io/docs/specification/v3_0/authentication/oauth2/
Here we can either map the name of the security scheme (instead of being arbitrary) to an actual name that's registered with the golem application, where the scheme is owned by a project
It's a very good idea to try this out with Github.
# Step 1 - define the security scheme
components:
securitySchemes:
oAuthSample: # <---- arbitrary name
type: oauth2
description: This API uses OAuth 2 with the implicit grant flow. [More info](https://api.example.com/docs/auth)
flows:
implicit: # <---- OAuth flow(authorizationCode, implicit, password or clientCredentials)
authorizationUrl: https://api.example.com/oauth2/authorize
scopes:
read_pets: read your pets
write_pets: modify pets in your account
# Step 2 - apply security globally...
security:
- oAuthSample:
- write_pets
- read_pets
# ... or to individual operations
paths:
/pets:
patch:
summary: Add a new pet
security:
- oAuthSample:
- write_pets
- read_pets
...
The purpose of this ticket, is to ensure #1060 works with a proper OpenAPI spec. With #1060, in OSS version, you may need a dictionary of security schemes with no references to project while in cloud, this scheme is owned per project.
The callback auth URL is part of the OAuth2 app settings in Github, as an example, and this would imply these need to be stored in Golem as part of the details of the security scheme
Once #1060 is done, decide the configuration setup. The above workflow will be slightly different in terms of its configuration set up compared to making a normal application work with the workflow, especially configuring the redirections. Setting up the workflow is quite flexible in normal applications, and that may not be the case when it comes to API Gateway, especially the redirections. Note that user is not writing any code using Rib or injecting logic within a component. This would imply most of the heavy lifting is done within the OpenAPI spec.
The bare minimum that we expect is the following:https://swagger.io/docs/specification/v3_0/authentication/oauth2/ Here we can either map the name of the security scheme (instead of being arbitrary) to an actual name that's registered with the golem application, where the scheme is owned by a project
It's a very good idea to try this out with Github.
The purpose of this ticket, is to ensure #1060 works with a proper OpenAPI spec. With #1060, in OSS version, you may need a dictionary of security schemes with no references to project while in cloud, this scheme is owned per project.
The callback auth URL is part of the OAuth2 app settings in Github, as an example, and this would imply these need to be stored in Golem as part of the details of the security scheme