How to implement email change with verification

[cat]

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!

[andrea]

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

[cat]

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.

[jmussman]

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

[cat]

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?

[andrea]

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?

[cat]

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

[jmussman]

@cat Just FYI to get the Postman to work (your second response in this thread) the Origin header has to be set to the same as the original application request that set the “sid” (session) cookie. I don’t know of any documentation that states this. The GET request doesn’t require this so I suspected a header issue and and I isolated the Origin header in the POST request. I confirmed this is only an issue if the “sid” cookie is relied on to provide authorization for users/me in the API. If you use a bearer access token Origin doesn’t matter.

I still don’t have an answer for your last question to Andrea which is the important one, I hope she finds one

[jmussman]

@cat FYI I did a whole bunch of testing to verify some stuff, the concise results are:

• My developer accounts have a secondEmail, but it doesn’t appear in the user interface (look at settings) and it isn’t used. Just FYI in case you’re trying it there.
• If you change either the primary email or secondEmail through the API, it assumes it is verified (look at the users/me with GET), putting the burden of verification on the application. Tested in both developer and production tenants.
• If an admin changes a user email the same thing happens, it is assumed to be verified.
• Confirmation that if you change the primary email the username changes. Support says that you could separate them in the request and make them different, but in default tenants the user cannot change the username property so it is rejected with a 403. You can change the rights for the user in the profile editor.

So the behavior is the same in a production tenant for updating secondEmail; it just puts it in as verified. @andrea, that leaves us back at the original question: can we change the secondEmail and have it marked as unverified and get a verification email sent? Probably a support ticket needs to be opened about this @cat.

[andrea]

yeah, I agree, a support case would likely be the best way to investigate @cat’s issue further.

[cat]

Thank you Joel for those details! It is very helpful and will help many others as well I’m sure. Sounds good. I will open a support case. I’ll post back here with any progress.

[cat]

I reached out to support, and they said that the feature does not exist. If you are interested in this feature, please upvote the Okta Ideas post I made for it: https://ideas.okta.com/app/#/case/144087