Supported Identity Providers
In an exchange of authentication and authorization data, an identity provider
securely asserts the identity and access rights of a set of users. Your Open
edX site is the service provider that allows the users access on the basis of credentials sent by an identity provider.
For example, your Open edX site hosts the courses of three different
organizations. When you configure the Open edX site to be a service provider,
and configure each of the three organizations to be identity providers, you
permit learners who have valid user credentials at any of those organizations
to access the Open edX site.
You can enable third party authentication between your Open edX site and many
types of identity providers. The Open edX platform provides support for
three types of identity providers.
Supported Identity Providers
The Open edX platform has integrated support for the following providers.
- OAuth based providers (OAuth2 and the older OAuth v1). Google, Facebook,
LinkedIn, and Azure Active Directory are available by default. Any other
OAuth backends supported by python-social-auth v0.2.12 can be enabled by
changing a configuration setting. People in the Open edX community sometimes
use “third party auth” to refer to Google or Facebook integration. Single
sign on, or “SSO”, and “third party auth” are largely interchangeable terms
for the purposes of this document.
- Security Assertion Markup Language (SAML) version 2.0, or Shibboleth.
SAML is an SSO standard mostly used by universities and corporations.
Shibboleth is the name of a particular implementation of SAML, commonly used
by higher education institutions. People in the Open edX community sometimes
use “SSO” to refer to SAML or Shibboleth. “SSO” and “Third Party Auth” are
largely interchangeable terms for the purposes of this doc. For more
information, see Integrating with a SAML Identity Provider.
- LTI. Users can use Learning Tools Interoperability® (LTI®) to
authenticate.
Provisionally Supported Identity Providers
The Open edX platform also includes limited support for the following SSO
providers.
- OpenID
- Apache-hosted Shibboleth
- SSL client certificates
- Central Authentication Service (CAS)
These providers are part of the external_auth app, tend to be older and less
robustly tested, and have a much more limited feature set. These providers are
included in the source code but are not officially supported.
Integrating Identity Providers
Regardless of the standard that the identity provider you want to integrate
with uses, you begin by enabling the third party authentication
feature for your site.
For example, your Open edX site hosts the courses of three different
organizations. When you configure the Open edX site to be a service provider,
and configure each of the three organizations to be identity providers, you
permit learners who have valid user credentials at any of those organizations
to access the Open edX site.
If you are using edX as an LTI tool provider to a external learning management system
or application, you can set up an authentication workflow between your Open
edX site and the system that is the LTI tool consumer. For more information,
see Options for LTI Authentication and User Provisioning and
Configuring Open edX User Authentication for LTI.
Integrating Third Party Authentication with edX Edge
Institutions that have partner memberships with edX can integrate third party
authentication between their campus or institutional authentication systems and
the edX Edge site. Learners at sites that enable third party authentication can
use their campus credentials to authenticate into edX Edge.
These procedures require collaboration between members of the development
operations (DevOps) and information technology (IT) teams at your partner
institution and the DevOps team at edX, facilitated by your edX partner
manager.
Security Assertion Markup Language, version 2.0 (SAML 2.0) is the standard that
edX uses for the exchange of authentication and authorization data with
institutional partners. Because it is built with SAML, this service
is compatible with the Shibboleth single sign on system.
In the exchange of authentication and authorization data, your edX partner
institution is an identity provider (IdP) that securely asserts the identity
and access rights of a set of users. EdX is the service provider (SP) that
allows the users access on the basis of those credentials.
All procedures described in this section should be performed by a member of
your institution’s IT team who is familiar with your institutional Shibboleth
system. The designated IT contact must have access to test and production
accounts, and be able to make configuration changes.
Integrating an institutional IdP with edX Edge requires a preliminary
validation phase.
- All procedures are completed between a test Shibboleth account at the
partner institution and the edX staging instance (“edX stage”).
- After validation, all procedures are completed between the partner’s
production system and edX Edge.
Your designated IT contact must set up or identify a Shibboleth test account,
and securely transmit its credentials to edX, before integration testing can
begin.
Note
The edX DevOps team prefers PGP encryption of account credentials.
Other secure methods for transmitting credentials can be accommodated if
necessary.
On your Shibboleth system, use the SAML metadata obtained from the XML file to
add edX stage, and then edX Edge, to your whitelist of authorized service
providers.
For example, you might add the following information to your
$IDP_HOME/conf/relying-party.xml
file for edX Edge.
<MetadataProvider xsi:type="FileBackedHTTPMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"
id="edxEdgeMetadata"
metadataURL="https://edge.edx.org/auth/saml/metadata.xml"
backingFile="/tmp/idp-metadata-edx-edge.xml" />
For more information about defining a metadata source on a Shibboleth system,
see the Shibboleth configuration wiki.
To complete the integration between a Shibboleth system and an edX system, you
send a copy of the assertion document with the following information to your
institution’s edX partner manager.
Metadata: The URL for your Shibboleth IdP metadata XML file.
User Attributes: A list of the values that you want your Shibboleth system to
assert when users sign in to edX Edge.
For more information about how you can work with edX to configure user
attributes effectively, see Configure User Attributes.
You send this information for both your test and production accounts so that
integration can be validated.
Your edX partner manager notifies you when integration with your IdP is
complete.
To verify that users can use their campus or institutional credentials for your
IdP to sign in to Edge, follow these steps.
Go to the Edge registration page. The page should include the
institutional sign in button.
Select Use my institutional/campus credentials. The list of providers
that appears should include your IdP.
Select your own IdP. The landing page for your Shibboleth system should
open.
Configuring your Open edX Site as a SAML Service Provider
The first step in configuring your Open edX site to act as a SAML SP is
to create a credential key pair to ensure secure data transfers with identity
providers. To complete the configuration procedure, you configure your Open edX
site as a SAML SP, which creates your metadata XML file.
After you complete this configuration, you can share your metadata file with
SAML identity providers, and configure them to assert identity and access
rights for users to your installation. For more information, see
Integrating with a SAML Identity Provider.
To generate the keys for your Open edX installation, follow these steps.
On your local computer or on the server, open Terminal or a Command Prompt
and run the following command.
openssl req -new -x509 -days 3652 -nodes -out saml.crt -keyout saml.key
Provide information at each prompt.
Two files, saml.crt
and saml.key
, are created in the directory where
you ran the command.
Note
Configuration settings added to the lms.auth.json
file are reset
to their default values when you use Ansible to update edx-platform.
To configure an Open edX site with your public and private SAML keys, follow
these steps.
Open the edx/app/edxapp/lms.auth.json
file in your text editor.
Edit the file to add a section for the SAML keys. For example,
# SAML KEYS
.
In the new section, add the SOCIAL_AUTH_SAML_SP_PUBLIC_CERT
parameter
followed by a colon (:), a space, and the YAML literal style indicator (|).
# SAML KEYS
SOCIAL_AUTH_SAML_SP_PUBLIC_CERT: |
Open the saml.crt
file, copy its entire contents, and then paste them
onto the line after the SOCIAL_AUTH_SAML_SP_PUBLIC_CERT
parameter.
# SAML KEYS
SOCIAL_AUTH_SAML_SP_PUBLIC_CERT: |
-----BEGIN CERTIFICATE-----
SWP6P/C1ypaYkmS...
...j9+hjvbBf3szk=
-----END CERTIFICATE-----
Add the SOCIAL_AUTH_SAML_SP_PRIVATE_KEY
parameter followed by a colon
(:), a space, and the YAML literal style indicator (|).
# SAML KEYS
SOCIAL_AUTH_SAML_SP_PUBLIC_CERT: |
-----BEGIN CERTIFICATE-----
SWP6P/C1ypaYkmS...
...j9+hjvbBf3szk=
-----END CERTIFICATE-----
SOCIAL_AUTH_SAML_SP_PRIVATE_KEY: |
Open the saml.key
file, copy its entire contents, and then paste them
onto the line after the SOCIAL_AUTH_SAML_SP_PRIVATE_KEY
parameter.
# SAML KEYS
SOCIAL_AUTH_SAML_SP_PUBLIC_CERT: |
-----BEGIN CERTIFICATE-----
SWP6P/C1ypaYkmS...
...j9+hjvbBf3szk=
-----END CERTIFICATE-----
SOCIAL_AUTH_SAML_SP_PRIVATE_KEY: |
-----BEGIN RSA PRIVATE KEY-----
W1icmlkZN+FtM5h...
...s/psgLDn38Q==
-----END RSA PRIVATE KEY-----
Save and close the lms.auth.json
file.
By default, SAML is included as an approved data format for identity providers.
The default configuration of the /edx/app/edxapp/lms.env.json
file does not
explicitly include the THIRD_PARTY_AUTH_BACKENDS
setting.
If you have customized this file and added the THIRD_PARTY_AUTH_BACKENDS
setting to it, you might need to verify that the
third_party_auth.saml.SAMLAuthBackend
python-social-auth backend class is
specified for it. That backend is required before you can add SAML IdPs.
To verify that the SAML authentication backend is loaded on a devstack or
fullstack installation, review the /edx/app/edxapp/lms.env.json
file.
Advanced Third Party Authentication Features
The Open edX Third Party Authentication feature offers many advanced
configuration options and integration points that can be used to customize the
sign in experience for learners using specific third party providers. None of
the following features are required for a typical installation, but they may be useful.
Skip Email Verification
When you configure an OAuth2 or SAML provider in the Django admin, there is a
boolean Skip email verification for that provider. Normally, all users are
required to verify their email address by clicking a link in the verification
email that gets automatically sent to the user upon registration. When this
option is selected, Open edX trusts that the email address provided by the
external authentication provider is correct.
If a user registering with a provider that has this option enabled, and the
user’s email address matches the email address that was sent to Open edX by the
external provider, the user’s email address will be marked as verified, and no
verification email will be required. (However, the email address sent by the
external provider is only used to pre-fill the registration form, and the user
has a chance to edit the email address on the registration form before creating
their account. If they edit their email address so that it no longer matches
the email address sent by the external provider, the user will still be
required to verify their email address as usual.)
Hinted Sign In
When you link to Open edX, you can create “hinted links” that prompt the user
to sign in using a specific provider. For example, the following link
represents a typical link to an example course.
https://courses.example.com/courses/course-v1:OrganizationX+Course101x+1T2016/courseware/3eddbb5919544c229d34b3175debc6d6/f9900289d2d0474096d20d23a1eeed81/
The following link represents a hinted link to the same course. At the end of
the URL, ?tpa_hint=oa2-google-oauth2
has been added.
https://courses.example.com/courses/course-v1:OrganizationX+Course101x+1T2016/courseware/3eddbb5919544c229d34b3175debc6d6/f9900289d2d0474096d20d23a1eeed81/?tpa_hint=oa2-google-oauth2
When users select the typical link, they go to the sign in page. When they
select the hinted link, they receive a “Would you like to sign in using your
Google credentials?” prompt that includes a large button to use Google to sign
in, as well as a small button to use other sign in options.
The intended use case of this feature is for organizations that wish to provide
a link from an on-premise system (or a course in another LMS like Canvas) to a
course in Open edX. In that case, the organizations will want students to sign
in using the organizations’ SAML providers. By using hinted links, the sign in
and/or registration process will be simpler for students, as they won’t have to
select a sign in provider or enter a password.
To create a hinted link for an OAuth2 provider, append
?tpa_hint=oa2-providername
to any Open edX URL, where providername
is
the “Backend Name” value from the “Provider Configuration (OAuth)” section of
the Open edX Django admin.
To create a hinted link for a SAML provider, append ?tpa_hint=saml-idpslug
to any Open edX URL, where idpslug
is the “Idp slug” value from the
“Provider Configuration (SAML IdP)” section of the Open edX Django admin.
Auto-enrollment
Open edX has a feature that allows instructors, marketing teams, and others to
create links that automatically enroll students who click the link into a
specific course.
If you send users to {LMS base URL}/account/finish_auth
and include
course_id
, enrollment_action
, and optional course_mode
and
email_opt_in
parameters, the system auto-enrolls the user in the
specified course.
For example, the following URL would auto-enroll the user who clicks this link
into the edX Demo course (that course’s ID,
course-v1:edX+DemoX+Demo_Course
, has been url-encoded as the value of the
course_id
parameter). If the user is not signed in, they must sign in or
register first, and then they will be auto-enrolled.
https://courses.example.com/account/finish_auth?course_id=course-v1%3AedX%2BDemoX%2BDemo_Course&enrollment_action=enroll&email_opt_in=false
You can include the following parameters.
enrollment_action
: This is required to trigger the auto-enrollment
behavior. It must be set to either enroll
(for free courses) or
add_to_cart
(for paid courses). If add_to_cart
is used, the user will
be directed to the shopping cart page rather than instantly enrolled.
course_id
: This is required. The ID of the course to enroll the user in,
or add to cart, etc. It must be URL-encoded.
course_mode
: one of audit
, honor
, verified
, etc. Only applies
if enrollment_action is enroll
. If it’s not specified, and the course has
more than one mode, the user will be sent to the “track selection” page where
they can choose which track/mode to use. If honor
or audit
is
specified, the user will be instantly enrolled. If any other mode is
specified, the user will be sent to the payment/verification flow.
email_opt_in
: Can be true
or false
. If true, this indicates that
the user has consented to receiving marketing emails from Open edX and the
course partner.
This feature can also be combined with hinted sign in,
if you create a URL such as the following example.
https://courses.example.com/account/finish_auth?course_id=course-v1%3AedX%2BDemoX%2BDemo_Course&enrollment_action=enroll&email_opt_in=false&tpa_hint=oa2-facebook
Secondary Providers
When you configure an OAuth2 or SAML provider in the Django admin, there is a
boolean option to mark the provider as a Secondary provider. Normally,
third party sign in providers are displayed on the Open edX sign in and
register pages. However, secondary providers are not displayed directly on the
sign in or register pages. Instead, users see a button that says “Use my
institution/campus credentials”. Clicking that will bring up a separate menu
that lists all the secondary providers.
The intended use case of this feature is to keep the sign in/register page from
being cluttered with too many buttons.
SAML Attribute Requirements
When you integrate Open edX with a SAML provider, you can allow only some users
to sign in based on some criteria. For example, organizations may not want
alumni or guest users to be able to sign in to Open edX using their SAML
provider, even though those users have valid sign in credentials for the
organization.
Users can be filtered based on eduPersonEntitlement
attributes (supported
out of the box), or other attributes (requires custom code). For details on how
this can be set up, refer to this edx-code mailing list post.
Eliminating PII From Third-Party Authentication
Open edX sites and Open edX Edge do not require any personally identifiable
information (PII) about learners during third-party authentication. PII is
information that can be used to reveal an individual’s identity, such as a
name. Your identity provider (IdP) service can send only non-personal
identifiers to create Open edX site accounts for learners. If you configure
third-party authentication in this way, the Open edX site never receives PII
from your organization.
Note
The types of information that constitute PII and requirements for handling it
depend on the laws and regulations that apply to your organization. The
information in this documentation is intended to explain how Open edX sites
can be configured to handle learner data. You cannot rely on this
documentation as a source of legal guidance.
After you have configured a third-party authentication profile for an Open edX
site, the site’s sign-in page will display a button for users to access your
IdP service. Learners will access your IdP service and authenticate using their
organization credentials. Your IdP service will direct learners back to the
Open edX site’s sign-in screen with an authentication token.
The IdP authentication token includes an identifying string for a learner. This
identifier serves as a link between the identifying information that your
organization maintains for a learner and the Open edX account for that learner.
The identifying string does not need to include any PII for the learner. The
identifying string is sometimes referred to as an opaque identifier because it
does not make the identity of the learner visible.
When a learner uses third-party authentication to sign in to an Open edX site
for the first time, the Open edX site creates a learner account. The new Open
edX learner account is permanently associated with the identifying string
included in the IdP authentication token. Learners will be prompted to create
profiles by entering Open edX usernames, email addresses, and other information
in their accounts. Learners can take steps to minimize the PII in their
profiles. For more information, see
Minimizing PII in Account Profiles.
The following diagram shows how an IdP can direct a learner to an Open edX site to
create a learner account, without transmitting any PII.
You can download a report containing grades for all learners in the Open edX
courses that you run. The report includes the Open edX username for each
learner enrolled in the course, but the usernames may not correspond to learner
records that your organization maintains. If you need to match the scores for
Open edX site learners to the learner records that your organization maintains,
you can use the third- party authentication ID mapping REST API to retrieve the
user ID SAML attribute and matching Open edX username for a learner. For more
information about grade reports for Open edX courses that you run, see
Generate a Grade Report for All Learners in a Course.
The following diagram shows how an organization that uses third-party
authentication can match non-personally identifying Open edX learner usernames
with the records that the organization holds for those learners.
When your IdP directs a learner to an Open edX site for the first time, the
learner enters information to create an Open edX site account. The basic
information required for an Open edX site account is an email address, full
name, public username, password, and country. Learners may also provide
additional personal details such as gender, year of birth, and educational
background. While course teams have access to full registration information
for learners enrolled in their courses, only public usernames are used to
identify learners in course discussions and other public-facing course
interactions.
To minimize PII stored on an Open edX site, learners can limit the information
in their Open edX account profiles to the basic information required for an
Open edX site account. Additionally, learners may use random or nondescript
public usernames and create non-identifying email addresses to receive course
updates.
If you want to avoid transmitting PII for the Open edX learner accounts that
use third-party authentication, you should not include personally identifying
information in the authentication token. The only piece of information that is
required in the authentication token is the user ID, which should not be
personally identifying.
For more information about configuring the information in a third-party
authentication token, see Configure the SAML Identity Provider.
Organizations that use SAML to integrate their IdPs with Open edX need to
understand what personal information is provided to Open edX when users sign in
using SAML.
When a user uses SAML or Shibboleth to sign in to Open edX, the IdP
authoritatively asserts pieces of information about the user.
Each piece of information is called a SAML attribute. Each attribute has a
name and a formal identifier that is called an object identifier (OID)
uniform resource name (URN).
The following table lists some common attributes.
Name |
OID URN |
Example Value |
User ID |
urn:oid:0.9.2342.19200300.100.1.1 |
123456789 |
Full Name |
urn:oid:2.5.4.3 |
Donna Noble |
First Name |
urn:oid:2.5.4.42 |
Donna |
Last Name |
urn:oid:2.5.4.4 |
Noble |
Email |
urn:oid:0.9.2342.19200300.100.1.3 |
dnoble@school.edu |
eduPersonPrincipalName |
urn:oid:1.3.6.1.4.1.5923.1.1.1.6 |
dnoble@school.edu |
eduPersonEntitlement |
urn:oid:1.3.6.1.4.1.5923.1.1.1.7 |
urn:mace:school.edu:confocalMicroscope |
For more information about eduPersonPrincipalName
and
eduPersonEntitlement
, see eduPersonPrincipalName and
eduPersonEntitlement on the eduPerson Object Class Specification page.
When a new user uses SAML to sign in to Open edX, the IdP sends information
about the user to Open edX in the form of these attributes. These attributes
can be used to pre-fill the registration form.
For example, when a user signs in, their server may provide the following
information.
"urn:oid:0.9.2342.19200300.100.1.1: 123, urn:oid:2.5.4.3: John Smith,
urn:oid:0.9.2342.19200300.100.1.3: jsmith@school.edu"
Open edX saves the user ID because it is required to match future sign-in
attempts to the correct user account. The full name (John Smith
) and email
(jsmith@school.edu
) is pre-filled on the registration form, but if the user
edits those, Open edX saves only the new changed version. (For example, if the
user changes the email to jsmith@example.com
, Open edX would record the
user’s email as jsmith@example.com
and would not have any record of the
jsmith@school.edu
address.)
By default, Open edX expects the standard User ID field
(urn:oid:0.9.2342.19200300.100.1.1
) and uses that as the unique external
ID. Open edX can accept any set of attributes that a SAML IdP sends, as long as
one of the attributes is a unique, permanent identifier for the user being
authenticated. The URN or OID of the unique identifier must be specified in the
Open edX “Provider Configuration (SAML IdPs)” profile for the organization
(part of the Django administration console) in the User ID Attribute
field.
If you want to configure Open edX to always store all of the attributes that
the external IdP sends for each user, you can enable that with a
setting, as follows.
Sign in to the Django administration console for your base URL. For example,
http://{your_URL}/admin
.
Go to the SAML Configuration page, and then select Add SAML
Configuration. (Do not go to the SAML Provider Configuration page.)
In the Other Config Str section, add the following code.
"EXTRA_DATA": [ "attributes" ]
This setting causes all the attributes to be saved in the
social_auth_usersocialauth
table’s extra_data
column for every new SAML
user. This data is only accessible by accessing the database directly or by
going to the User social auths page of the Open edX LMS Django
administration console.
For organizations that want to avoid sending any personally identifiable
information to Open edX during the SAML sign in or registration process, we
recommend that the organization configure their SAML IdP to only send a single
attribute: a unique, permanent, opaque user identifier. This should be a
value that uniquely identifies any learner or staff member, but is different
from their organization ID or any other identifier they may have.
For reporting and analytics purposes when using an opaque user identifier, the
organization can use the Third Party Auth ID Mapping API to convert Open
edX user IDs found in reports or analytics back to these opaque organization
user identifiers. Organization partners can then convert each opaque user
identifier back to the official learner ID.
Third Party Auth ID Mapping API
Open edX has an API that can be used to retrieve the association between Open
edX user IDs and the unique user identifiers sent by the external platform.
When an Open edX course is used in an on-premise environment, and SAML, LTI, or
other SSO is enabled to allow learners to authenticate to edX using their on-premise credentials, normally an on-premise identity provider (IdP) sends an
identifier. This identifier is stored in edX and linked to the edX account.
Later, when learners return from an on-premise IdP, edX can authenticate the
learner using their edX account.
Because learners may create Open edX accounts using an alternative identity,
instructors may have difficulty identifying Open edX learners in their courses.
Grade records obtained from Open edX will only contain Open edX learner IDs,
which would be unknown to the on-premise system.
This API can be used for mapping between the edX user ID and the ID provided by
the IdP. This API provides information that allows instructors or course
support staff to figure out the identity of the on-premise learners who are
using the edX course. It also allows grade information coming from Open edX to
be appropriately associated to on-premise learners for uploading to an
on-premise learning management system (LMS) or learner information
system (SIS).
This API is intended to be consumed by on-premise middleware, which combines
the information from an on-premise system. The middleware communicates with the
premise system to get information about the course and enrollment, then uses
that information to control instructor access. The instructor can then perform
tasks such as obtaining the edX learner’s on-premise identity, uploading grades
back to their LMS or SIS, and making groups based on on-premise activities.
This API also helps with the issue where learners enter incorrect email
addresses and cannot activate their accounts, and then cannot authenticate with
Open edX through SSO because of the inactive accounts. With this API,
on-premise course support staff or instructors can provide the Open edX
operator with the learner’s real edX username instead of the ID that the
IdP passed over to Open edX, so that the Open edX operator does not have
to manually query the tables to figure out the mapping between the source
system ID and the Open edX username.
Using the Third Party Auth ID Mapping API
To use the Third Party Auth ID Mapping API, follow these steps.
- Have one or more third party auth providers enabled, and have learners who
have link their accounts to one or more of those providers.
- Set up an OAuth2 client. To do this, open the Django administration panel,
select OAuth2, select Client, select Add Client, and then enter
the following information.
- For User, create a dedicated user for this API.
- For URL, Redirect URL, enter a dummy value such as
http://localhost/
. The URL is not used for this API.
- For Client Type, specify Confidential.
- Leave other fields with the default values.
- Give the new client permission to this API. To do this, go to
Third_Party_Auth, select Provider API Permissions, and then select
Add Provider API Permission.
- Select the OAuth2 client that you just created, and select an external
authentication provider. This will give the new client access to query that
provider mapping.
The API is now available at {LMS base
URL}/api/third_party_auth/v0/providers/{provider_id}/users
. The API client
must use OAuth2 to authenticate before that endpoint will work. The
{provider_id}
value uses the same format as described in Hinted Sign In.
To test the API, follow these steps.
Use client credentials (from the django admin) to get the access token, as
follows.
curl --data "client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=client_credentials" http://localhost:8000/oauth2/access_token
Returns: {"access_token": "c1efde84445b2f256e1c80886b3f6d46339b84ee", "token_type": "Bearer", "expires_in": 31535999, "scope": ""}
Use the access token to issue requests to the API, as in the following
examples.
curl --header "Authorization: Bearer ACCESS_TOKEN" http://localhost:8000/api/third_party_auth/v0/providers/{provider_id}/users
curl --header "Authorization: Bearer ACCESS_TOKEN" http://localhost:8000/api/third_party_auth/v0/providers/{provider_id}/users?username=USERNAME1,USERNAME2
curl --header "Authorization: Bearer ACCESS_TOKEN" http://localhost:8000/api/third_party_auth/v0/providers/{provider_id}/users?username=USERNAME1&username=USERNAME2
curl --header "Authorization: Bearer ACCESS_TOKEN" http://localhost:8000/api/third_party_auth/v0/providers/{provider_id}/users?remote_id=REMOTE_ID1,REMOTE_ID2
curl --header "Authorization: Bearer ACCESS_TOKEN" http://localhost:8000/api/third_party_auth/v0/providers/{provider_id}/users?remote_id=REMOTE_ID1&remote_id=REMOTE_ID2
The following example shows a return value from the API.
{
"page": 1,
"page_size": 200,
"count": 8,
"results": [
{"username": "USERNAME1", "remote_id": "REMOTE_ID1"},
{"username": "USERNAME2", "remote_id": "REMOTE_ID2"},
]
}