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

add docs for generic oauth 2.0 connector #91

Merged
merged 3 commits into from
Apr 21, 2022
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions content/docs/connectors/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,6 +32,7 @@ Dex implements the following connectors:
| [OpenShift](/docs/connectors/openshift/) | no | yes | no | stable | |
| [Atlassian Crowd](/docs/connectors/atlassian-crowd/) | yes | yes | yes * | beta | preferred_username claim must be configured through config |
| [Gitea](/docs/connectors/gitea/) | yes | no | yes | alpha | |
| [Generic OAuth 2.0](/docs/connectors/oauth/) | no | yes | yes | alpha |

Stable, beta, and alpha are defined as:

Expand Down
74 changes: 74 additions & 0 deletions content/docs/connectors/oauth.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,74 @@
---
title: "Authentication Through an Generic OAuth 2.0 Provider"
linkTitle: "Generic OAuth 2.0"
xtremerui marked this conversation as resolved.
Show resolved Hide resolved
description: ""
date: 2021-03-15
draft: false
Copy link
Member

Choose a reason for hiding this comment

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

I think we should make it a draft and merge it to master. Once the feature is released, we can flip the switch.

Copy link
Member

Choose a reason for hiding this comment

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

This would also be a great opportunity to figure #92 out. @nate-double-u do you think you can help us out with that?

Copy link
Contributor

@nate-double-u nate-double-u Mar 16, 2021

Choose a reason for hiding this comment

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

I'd be happy to take a look.

[edit] #93

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should make it a draft and merge it to master. Once the feature is released, we can flip the switch.

Have to be careful with that -- this PR touches a couple files

toc: true
weight: 2050
Copy link
Contributor

Choose a reason for hiding this comment

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

This is the same weight as oidc -- which means it will be next to it in the menus. Is this a good position for this page?

Copy link
Contributor

Choose a reason for hiding this comment

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

Screen Shot 2021-03-15 at 11 43 55 AM

Copy link
Author

Choose a reason for hiding this comment

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

thx for pointing that out! Didn't think about this value as i took it from OIDC doc directly.

How is the weight being decided (relevance/importance/users number/time being added)? Though, this connector is indeed close to OIDC connector since OIDC is just a layer on top of oauth 2.0 protocol.

Copy link
Contributor

@nate-double-u nate-double-u Mar 15, 2021

Choose a reason for hiding this comment

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

Maybe we slot it in above OIDC then, thoughts @sagikazarmark?

Suggested change
weight: 2050
weight: 2045

Copy link
Member

@nabokihms nabokihms Mar 16, 2021

Choose a reason for hiding this comment

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

Sorry for interfering. I thought connectors should be in the order they appear in the table on the index page. If you want it to be above OIDC, you need to change its order in the table as well.

Copy link
Member

Choose a reason for hiding this comment

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

Personally, I'd like to see this list sorted by importance (arbitrary) and alphabetical. Eg.:

  • OIDC
  • OAuth 2.0
  • SAML
  • LDAP
  • Provider specific connectors in alphabetical order

So I guess for now it's fine under OIDC.

Copy link
Author

Choose a reason for hiding this comment

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

Set it to 2055 so it goes under OIDC. Also positioned it under OIDC in the connectors table.

---

## Overview

Dex users can make use of this connector to work with standards-compliant [OAuth 2.0](https://oauth.net/2/) authorization providers, in case those authorization providers are not already in the Dex connectors list.

## Configuration

The following is an example of a configuration for using OAuth connector with Reddit.

```yaml
connectors:
- type: oauth
# ID of OAuth 2.0 provider
id: reddit
# Name of OAuth 2.0 provider
name: reddit
config:
# Connector config values starting with a "$" will read from the environment.
clientID: $REDDIT_CLIENT_ID
clientSecret: $REDDIT_CLIENT_SECRET
redirectURI: http://127.0.0.1:5556/callback

tokenURL: https://www.reddit.com/api/v1/access_token
authorizationURL: https://www.reddit.com/api/v1/authorize
userInfoURL: https: https://www.reddit.com/api/v1/me

# Optional: Specify whether to communicate to Auth provider without
# validating SSL certificates
# insecureSkipVerify: false

# Optional: The location of file containing SSL certificates to commmunicate
# to Auth provider
# rootCAs: /etc/ssl/reddit.pem

# Optional: List of scopes to request Auth provider for access user account
# scopes:
# - identity

# Optional: Configurable keys for user ID look up
# Default: id
# userIDKey:

# Auth roviders return non-standard user identity profile
# Use claimMapping to map those user infomations to standard claims:
claimMapping:
# Optional: Configurable keys for user name look up
# Default: user_name
# userNameKey:

# Optional: Configurable keys for preferred username look up
# Default: preferred_username
# preferredUsernameKey:

# Optional: Configurable keys for user groups look up
# Default: groups
# groupsKey:

# Optional: Configurable keys for email look up
# Default: email
# emailKey:

# Optional: Configurable keys for email verified look up
# Default: email_verified
# emailVerifiedKey:
```