https://github.com/isotes/traefik-outgoing-oauth2-cc
Outgoing OAuth2 Client Credentials Traefik Plugin
https://github.com/isotes/traefik-outgoing-oauth2-cc
oauth2-client traefik traefik-plugin
Last synced: 4 months ago
JSON representation
Outgoing OAuth2 Client Credentials Traefik Plugin
- Host: GitHub
- URL: https://github.com/isotes/traefik-outgoing-oauth2-cc
- Owner: isotes
- License: apache-2.0
- Created: 2025-03-03T07:06:58.000Z (over 1 year ago)
- Default Branch: main
- Last Pushed: 2025-03-05T05:29:03.000Z (over 1 year ago)
- Last Synced: 2025-03-12T09:37:17.471Z (about 1 year ago)
- Topics: oauth2-client, traefik, traefik-plugin
- Language: Go
- Homepage:
- Size: 14.6 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Outgoing OAuth2 Client Credentials Traefik Plugin
This is a middleware plugin for [Traefik](https://traefik.io/) to authorize *outgoing* requests using [OAuth2 Client Credentials Flow](https://datatracker.ietf.org/doc/html/rfc6749#section-4.4). The main idea is to use this plugin for separation of concerns in front of an external target.
Install manually or from the [Traefik Plugin Catalog](https://plugins.traefik.io/plugins/67c5fc454e61aa8e06b2536c/outgoing-o-auth2-cc).
This fulfills the same goal as [Upstream OAuth](https://plugins.traefik.io/plugins/63cd79ab3cccb4a7200f6f54/upstream-o-auth). Apart from a different set of configuration options, this plugin does not have any dependencies beyond the Go standard library. The disadvantage is that the authorization implementation may be more brittle.
## Configuration
### Static
Enable the plugin in the Traefik Static configuration.
```yaml
experimental:
plugins:
outgoing-oauth2-cc:
moduleName: github.com/isotes/traefik-outgoing-oauth2-cc
version: v1.0.1
```
### Dynamic
Specify the necessary information for performing the Authorization Grant.
Credentials: if user/pass are specified, the 'Authorization' header is computed with the Basic Auth credentials. By default, both the user and password are first encoded with the 'application/x-www-form-urlencoded' algorithm before computing the Basic Auth header as specified in the RFC,. Since not all OAuth2 servers are compliant, it is possible to skip the encoding step by setting `basicAuthSkipEncoding: true`. Finally, is also possible to pre-compute the 'Authorization' header and set it directly in the `headers` section below. For this reason, the `user` and `pass` fields are optional.
```yaml
http:
middlewares:
example-outgoing-oauth2-cc:
plugin:
outgoing-oauth2-cc:
trace: false # optional: enable additional debugging (incl. the result of token requests)
authGrantRequest:
url: https://example.com/request-token
user: foo # optional: the user for basic auth; alternatively, use a pre-computed 'Authorization' header value
pass: ~file~/secrets/password.txt # the password (here: read from a file)
scope: read # optional: the access token scope
expiresMarginSeconds: 10 # optional: the margin in seconds subtracted from the expires_in response (default & mininum: 1)
basicAuthSkipEncoding: false # optional: set to true to disable url-encoding of user/pass for non-RFC-compliant authorization servers
headers: # optional HTTP headers for the Client Authentication request
- name: X-Bar
value: ~base64~env~BAR_VALUE # the value is read from the environment variable BAR_VALUE and interpreted as base64
- name: X-Info
value: important
```
The fields `url`, `user`, `pass`, `name`, and `value` provide flexibility for specifying their values. The value is used directly as a string unless it starts with `~`. Then the value is parsed as `~[~]~`:
- `` is optional and specifies the encoding of the value. Currently, only `base64` is supported (standard alphabet as well as URL-safe alphabet).
- `` is required and specifies the source of the value
- `~file~XYZ` reads the value from the file `XYZ`
- `~env~XYZ` reads the value from the environment variable `XYZ`
- `~direct~~XYZ` uses the value `~XYZ` directly (only required if the value starts with `~` or if base64 encoding is required)
## Behavior
The plugin has a simple logic: if a token is not known or has expired, a Client Authentication request is made to obtain an Access Token. If this is successful, the original request is modified by setting the 'Authorization' header to 'Bearer ' and continued; the token is kept in memory until it expires.
If the Authorization Server does not return status code 200, that response is returned to the original client. If another issue occurs, e.g., while parsing the response of the Authentication Server, the plugin itself returns an HTTP 500 error. In both cases, the original request is not performed.
This plugin does not perform token refresh and instead always uses Client Authentication requests.
```mermaid
sequenceDiagram
Client->>MW: Request
opt unknown token or expired
MW->>Authorization Server: Client Authentication
Authorization Server->>MW: Access Token
break HTTP Status != 200
MW->>Client: Response from Authorization Server
end
break Auth Response Parsing Error
MW->>Client: HTTP 500 error from MW
end
end
MW->>Target: Request with Bearer Token
Target->>Client: Response
```
[Mermaid Live](https://mermaid.live/edit#pako:eNp9kk1rwzAMhv-K5nMHYbBLYIXuA3YJlDVQGLl4iZqaNFIm2-u20v8-O2mbMcJ8iGXrffXIdg6q5ApVqiy-e6QSH42uRbcFQRgPO4PkrufzbJ3CS1RYN2SGL3cOPDXEewLHDRKwAH52RrAaFHFk61Bh4d2WxXxrZ5hghfKBkp4AEJNhNmWfHZ1TplM3i7JEayGP1NHwJqgbeM7zJaycdt7C1R3cJMmouDQ0oOOxbMdkETbC7SRxNCNVf1nRMNZYarGGangSYfkH2nd4mySAUTigs_UEqA-GsC-Qa6nRXR4D9ibg71ELyu-7GGQTp1Qz1aK02lThzQ9RXKhw9y0WKg1hpaUpVEHHoNPe8eqLSpU68ThTwr7eqnSjdzasfFdpd_5bLrudplfm8_r4A3SHwZw)
## License
[Apache 2.0](LICENSE)