- Home
- Lifecycle Management
- Facebook IdP
Overview
Okta manages connections to Identity Providers for your application, sitting between your application and the Identity Provider that authenticates your users. You can set up Facebook as an Identity Provider for your applications and allow users to sign in to the application using their Facebook account. You can link the user's Facebook account to an existing Okta user profile or choose to create a new user profile using Just-In-Time (JIT).
Overview
You can set up Facebook as an Identity Provider (IdP) for your application so your users can sign in to your application using their Facebook account. Okta manages connections to IdPs for your application, sitting between your application and the IdP that authenticates your users.
Prerequisites
Installing Facebook as an IdP requires:
- An Okta organization within the okta.com or oktapreview.com domains. You can create a developer org for free.
- An external application that requires user authentication.
- A Facebook for Developers account if you don't already have one.
Procedure
- Register your application in Okta.
- Create a client application on Facebook.
- Create the identity provider in Okta.
- Create the authorization URL.
Register your app integration in Okta
An Okta app integration is required to consume the response from Facebook after authentication and authorization. You can use either an existing OpenID Connect (OIDC) app integration or create a new one. Users that sign in for the first time are created within Okta and assigned to your app integration.
- Sign in to your Okta organization with your administrator account.
- From the Admin Console side navigation, click Applications > Applications.
- Click Add Application.
If you want to add an existing OIDC app integration from the Okta catalog:
- Enter the name of the app integration in the Search... text box.
- On the catalog page for the app integration, click Add.
- Enter a label for your copy of this app integration. Click Done to add it to your org.
- On the Assignments tab, click Assign to assign the app integration to any user or group in your org. Click Done when the assignments are complete.
If you need to create a new OIDC app integration:
- Click Create New App.
- Select the appropriate Platform for your external application. Select OpenID Connect for the Sign on method, and click Create.
- Enter a name and, optionally, upload a logo for your new app integration.
- Add one or more Login redirect URIs. This URI is the Redirect URI location where the user is directed after they authenticate with Facebook.
- Click Save to finish creating your Okta app integration.
- On the General tab of your Okta app integration settings page, click Edit in the General Settings section.
- For the Allowed grant types setting, enable the Implicit (Hybrid) option. The Allow ID Token with implicit grant type option is selected automatically. Using the Implicit flow streamlines authentication by returning tokens without introducing any unnecessary additional steps. It allows you to get an ID token quickly, which makes it easy to test your configuration. The Authorization Code grant flow is also supported.
- Click Save to confirm your changes.
- On the Assignments tab, you can assign the app integration to a specific user or group. Click Done when the assignments are complete.
To get the client credentials for your app integration:
- On the General tab, copy the Client ID value from the Client Credentials section to complete the authorization URL step.
Create a client application on Facebook
-
On the Facebook for Developers site, create an app using the Create an App guide. When asked what you need your app to do, select Build Connected Experiences.
-
After you create the app, click Set Up in the Facebook Login tile on the Add Products to Your App page of the Facebook for Developers Console.
-
Select Web as the platform for your app.
-
In the Site URL box, enter the Okta redirect URI. The redirect URI sent in an authorization request from the client needs to match the redirect URI in the IdP. This URI is where the IdP returns the authentication response (the access token and the ID token). It needs to be a secure domain that you own. This has the same structure for most IdPs in Okta and is constructed using your Okta subdomain and the callback endpoint.
For example, if your Okta subdomain is called
company
, then the URL is:https://company.okta.com/oauth2/v1/authorize/callback
. If you have configured a custom domain in your Okta Org, use that value to construct your redirect URI, such ashttps://login.company.com/oauth2/v1/authorize/callback
. -
Click Save, then click Next until you exit the Facebook wizard.
-
In the dashboard for your Facebook app, open Facebook Login > Settings.
-
Under Client OAuth Settings, find the Valid OAuth Redirect URIs section and paste the redirect URI. Click Save Changes at the bottom of the page.
-
In the dashboard, open Settings > Basic.
-
Copy the App ID and the App Secret values so you can add them to the Okta configuration in the next section.
Note that there may be additional settings on the Facebook App Dashboard that you can configure for the app. The steps in this guide address the quickest route to setting up Facebook as an IdP with Okta. See the Facebook documentation for more information on additional configuration settings.
Add the identity provider in Okta
- In the Okta Admin Console for your org, click Security > Identity Providers.
- Click Add Identity Provider, then Add Facebook.
- Fill in the details for your Facebook connection:
- Name — Enter a name for this IdP configuration.
- Client ID — Paste the generated App ID from your Facebook application.
- Client Secret — Paste the generated App Secret from your Facebook application.
-
Scopes — Leave the defaults. By default, Okta requires the user's
email
attribute when creating and linking the user to Okta Universal Directory. For more information about these settings as well as the Advanced Settings, see Social Identity Provider Settings.
- Click Add Identity Provider.
- Click the arrow next to the IdP name to expand. Copy both the Authorize URL and Redirect URI values.
Create the authorization URL
When you created the identity provider in Okta, it generated an Authorize URL that contained several blank parameters to test the authorization flow when the user authenticates with Facebook.
Paste that Authorize URL to a text editor and replace the blank parameters with the following values:
-
client_id
— Use theClient ID
value that you obtained from your Okta app integration. For example,0oawjqpb2wcUAWM8C0h7
. This value isn't theApp ID
from your Facebook application. -
response_type
— Determines which flow is used. For the Implicit flow, set this toid_token
. For the Authorization Code flow, set this tocode
. -
response_mode
— Determines how the authorization response should be returned. Set this value tofragment
. -
scope
— Determines the claims returned in the ID token. Include the scopes that you want to request authorization for and separate each with a%20
(space character). You need to include at least theopenid
scope. You can request any of the standard OIDC scopes about users, such asprofile
andemail
, as well as any custom scopes specific to your IdP. -
redirect_uri
— The location where Okta returns a browser after the user finishes authenticating with Facebook. This URL should start withhttps
and must match one of the redirect URIs that you configured in your app integration. -
state
— Protects against cross-site request forgery. This can be set to any value. -
nonce
— A string included in the returned ID token. Use it to associate a client session with an ID token and to mitigate replay attacks. This can be set to any value.
For a full explanation of all of these parameters, see the /authorize
request parameters.
An example of a complete URL looks like this:
https://myapp1.okta.com/oauth2/v1/authorize?idp=0oaqtill1MKXRE6Av4x6&client_id=0oawjqpb2wcUAWM8C0h7&response_type=id_token&response_mode=fragment&scope=openid%20email&redirect_uri=https%3A%2F%2Fexample.com%2Foauth2%2Fv1%2Fauthorize%2Fcallback&state=WM6D&nonce=YsG76jo
Test
To test your authorization URL, enter the complete authorization URL in a browser. Testing this link in your browser's privacy or incognito mode avoids false positive or negative results.
Alternatively, you can create a simple web page with a link that simulates the user sign-in attempt. The HREF value for that link is the authorize URL:
<a href="https://myapp1.okta.com/oauth2/v1/authorize?idp=0oaqtill1MKXRE6Av4x6&client_id=0oawjqpb2wcUAWM8C0h7&response_type=id_token&response_mode=fragment&scope=openid%20email&redirect_uri=https%3A%2F%2Fexample.com%2Foauth2%2Fv1%2Fauthorize%2Fcallback&state=WM6D&nonce=YsG76jo">Sign in with Facebook</a>
If everything is configured properly:
- After the user clicks the link, they get a prompt to sign in with Facebook.
- After successful authentication, the user is redirected to the redirect URI that you specified, along with an
id_token=
fragment in the URL. The value of this parameter is your Okta token. - If something is configured incorrectly, the authorization response contains error information to help you resolve the issue.
This tests your authorization URL as an HTML link. For information on using the Okta Sign-in Widget, Okta-hosted Sign-in Page, or AuthJS to test your authorization, see Use the Identity Provider to sign in.
Related content
- Okta - Add an external Identity Provider
- Facebook - Facebook Login documentation
Support
If you need help or have an issue, post a question in our Developer Forum.
Functionality
Add this integration to enable authentication and provisioning capabilities.
Authentication (SSO)
- API
- Event Hooks
- Inbound Federation
- Outbound Federation
- RADIUS
- SAML Security Assertion Markup Language is an open standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP) that does not require credentials to be passed to the service provider.
- Workflow Templates
- Workflows Connectors
- SWA Secure Web Authentication is a Single Sign On (SSO) system developed by Okta to provide SSO for apps that don't support proprietary federated sign-on methods, SAML or OIDC.
- OIDC OpenID Connect is an extension to the OAuth standard that provides for exchanging Authentication data between an identity provider (IdP) and a service provider (SP) and does not require credentials to be passed from the Identity Provider to the application.
- WS-Federation
Provisioning
- Create Creates or links a user in the application when assigning the app to a user in Okta.
- Update Okta updates a user's attributes in the app when the app is assigned. Future attribute changes made to the Okta user profile will automatically overwrite the corresponding attribute value in the app.
- Deactivate Deactivates a user's account in the app when it is unassigned in Okta or their Okta account is deactivated. Accounts can be reactivated if the app is reassigned to a user in Okta.
- Attribute Sourcing The application can be defined as the source of truth for a full user profile or as the source of truth for specific attributes on a user profile.
- Sync Password Push either the users Okta password or a randomly generated password to the app. This feature is not required for all federated applications as user authentication takes place in Okta, however some apps still require a password.
- Group Push Push existing Okta groups and their memberships to the application. Groups can then be managed in Okta and changes are reflected in the application.
- Group Linking Link Okta groups to existing groups in the application. Simplifies onboarding an app for Okta provisioning where the app already has groups configured.
- Schema Discovery Import the user attribute schema from the application and reflect it in the Okta app user profile. Allows Okta to use custom attributes you have configured in the application that were not included in the basic app schema.
- Attribute Writeback When the application is used as a profile master it is possible to define specific attributes to be sourced from another location and written back to the app. For example the user profile may come from Active Directory with phone number sourced from another app and written back to Active Directory.