How to implement email change with verification

On the end user settings page, users can edit their email address and/or their secondary email address. When they do this, an email verification is sent to the new address before the change goes through. I could not find any Okta APIs that support this feature. Do they exist? Or how can we achieve this same thing?

Thanks!

Did you take a look at this API call: POST /api/v1/users/me

I tried that using Postman with the interceptor turned on. It did not work, I’m getting 403 Forbidden. When I change the request mode to GET, it goes through fine. But when I change it to POST, it shows 403 Forbidden. The request body contains a JSON profile object with my updates.

Hi cat!

I’m jumping in here because your original question was one I had on my to-do list to verify (pun intended).

First to address your last thing, “/users/me” works if either the session cookie or the API access token is passed with the request (from the org authorization server, not a custom authorization server including default). So, if you capture cookies with the Postman interceptor and Postman sends the session cookie with the request it should work. I verified the API call over the weekend. I think maybe something is amiss in your interceptor configuration. Maybe you’re not hanging on to the session cookie?

Number two, just FYI developer accounts for me don’t seem to ever send an email to the secondEmail address now. This changed about a year ago. Production accounts still do. So if you are using a developer account for testing that could be an issue. @Andrea, any thoughts on that?

Number three: I want to refer Andrea back to the original question about generating a confirmation email. As I said earlier, this was on my list because when you change the email or secondEmail via “me” using POST it just changes them blindly. If there is a way to force a confirmation email I’d love to know it because I too have not found that in the API. Maybe it’s a developer vs production tenant thing?

Number four: FYI, if you change the email address it changes the login too. If you don’t want that, you have to specify both “email” and “login” in the data to the POST call to “me”. But I’m guessing for your circumstances this is not an issue.

Joel

1 Like

Thanks Joel, that is all helpful information. As for Postman - it’s strange that the call works fine if I switch the request mode to GET. It’s only the POST version that fails. If I wanted to use a API access token then would I need to make my test user an admin, log in with their account, create one for them, and then use it in the users/me request? Otherwise how would Okta know who “me” is in that context?

Without the API token (which, you’re right, can only be generated by Admins), the ‘me’ context is ascertained by the Okta session cookie (‘sid’). If you log into Okta in the browser, you’ll be able to access the /users/me endpoint in another tab based on the presence of this cookie.

@jmussman I actually hadn’t seen that behavior difference between a dev and a production org. So you’re saying the production org behaves as desired?

@andrea how can we trigger the email-based flow to verify the new email set by the POST to /users/me?