What’s the best practice for implementing a non-okta login page? We have clients that want to host their own login pages. What is the process for authenticating users through a remote login page, but access OKTA for an authorization code, followed by id and access token grants?
Again, OKTA docs are not very clear…
The Okta Sign-In Widget is a JavaScript library that gives you a fully-featured and customizable login experience which can be used to authenticate users on any website.
Authenticate users against OKTA stored data, or remote stored data? We don’t want user information in OKTA, we only want to authenticate them through a custom IdP, then grant tokens.
@shouttag_mike So it sounds like clients are going to implement their own login with their own identity provider? I think you could use Social Login and configure any OAuth 2 compliant clients (would require some coordination between your Okta admins and your clients). The okta-signin-widget supports social login, but will also show the okta portion if not modified. Hope this helps.
To add to @ccrouch’s reply, you can add any of the identity providers mentioned here. Once the identity providers are configured, you can enable JIT so that, if the user is not present in Okta, it will be automatically created based on the details received by the Identity Provider.
1 Like
There in lies my question, what and how do we provide the details to OKTA via the OKTA /callback redirect?
If you are implementing an OpenID Connect Identity Provider, then you would need to provide an authorization code to Okta. From here, Okta, using the client ID and client secret specified in the IdP configuration inside the Okta tenant admin interface, will exchange the authorization code for an access token.
1 Like
Use the Okta sign in and style it in the manner that the customer wants.