We have a created a custom MVC .NET application that integrates with OKTA (using OpenID connect as the protocol). In our new user registration page currently, we collect the user information and call the OKTA SDK (Okta.Core) dlls to create a user :
var user = new User(model.Login, model.Email, model.FirstName, model.LastName);
user = usersClient.Add(user, true);
This currently sends an activation email. After the user activates the account (sets a password and other profile information), we would like to have the user redirected to our custom application. Is there a way to specify this in the admin console or via code currently?
If you were to use Tom’s proposed flow, your app would be in-charge of displaying screens to complete the registration of the user via Okta’s APIs after you received back the activationToken (his flow assumes user is created with a password).
If you don’t want to handle the setting of the password on your screens you can setup your Okta activation emails to redirect after activation. The redirect url must be a Okta relative url:
The drawback to this is that ALL activation emails from your Okta org will be sent to this url. If you have any other types of users in your org setting the password in your application probably makes the most sense for you.
Thanks for your response. We were hoping to avoid capturing the password in our custom application for security reasons and hence was redirecting the OKTA activation link. Also the 2nd approach of redirecting the url will not work if all activation emails (for other applications as well) will be sent to this url. Are there any other “work in progress” solutions for this feature and if so do you happen to know the timelines of release etc., since from the other post it looks like there are other clients as well looking for this feature.
Thanks
Kay
As Tom mentioned in the link I posted one potential solution we are working toward releasing soon (not sure on exact date) is our Self-Service Registration.
Registration-as-a-service - a set of API calls that will allow you to sign up users on front ends, like web apps and mobile apps. This will operate in two modes
Email Verification required - the user MUST activate by verifying their email
Email Verification deferred - the user is allowed to login without verifying their email
Email Verification-as-a-service - a set of API calls that allow you to send emails to your end-users and will store application context so that Okta can take action and get back to your application.
Does this sound like more of the use case you are trying to support?
Yes,
•Email Verification-as-a-service - a set of API calls that allow you to send emails to your end-users and will store application context so that Okta can take action and get back to your application.
Is what we are looking for. Do we have approximate timelines around which this will be released - 6 months vs 9 vs a year?
@tkirk-okta I am also interested in this. This seems to be a common problem. I easily found 5 other questions related to this and they’re all still waiting
@dragos@tom FYI since you are engaged in some of these other linked threads. If this “email verification as a service” functionality has been in the works for over 3 years, was it just deprioritized or was it scrapped?
Ok my team has found a solution for this problem. It involves using a partially documented Okta API parameter.
This parameter is used in two places by Okta as far as I know: Forgot Password, and Self-Service Registration. The Forgot Password use case is documented here Authentication | Okta Developer See the note about The optional parameter relayState:
What my team found is that this optional parameter relayState can also be submitted as a part of the self-service registration request. We have modified our signin widget to submit this parameter.
So in the POST to https://{okta-org-base-url}/api/v1/registration/{id}/register you have the following:
Then, after the user verifies their email, they will be redirected to the URL that you passed in the relayState parameter. The domain of the URL must be added to your Trusted Origins.
If you are working with a forked copy of the okta-signin-widget, you can implement this by adding the following to the fetchInitialData() function in RegistrationController.js:
The code to submit the relayState value is already present in toJSON() in RegistrationController.js. See here.
To use this same solution for the redirect after forgot password, you can add the following to the initialize() function in ForgotPasswordController.js:
