How is the provisioning invitation URL generated?

Hey there @TimBatist

The {SOME_SORT_OF_STRING} value is actually an invitation token generated server-side when a user is invited.

If I understand you correctly, you would like to have full automation of provisioning 1Password accounts.

From our end there will always be a manual step for the invitee to check their e-mail inbox for the invitation, this is so that the end user has an opportunity to record their secret key and decide on their password.

Hello @"Justin.Yoon_1P"

Thank you for your response.

I do understand that, and why, checking the mail is a manual step. Actually, we don't want our employees to have their secret key. We (security department) are logging the employee where necessary. If the employee loses their password, we will start the recovery procedure. Besides that, we are generating the password for the employee, because we use password generation instead of letting the employee choosing a probably less secure password. This is why we don't need the employee to check their mailbox.

However, because we want to automate this step, we need to extract the invitation link in that email. If there is no way for us to regenerate that URL, we need to find a way to access the employee's mailbox to retrieve the URL, which are complicated extra steps. So for us it would be very nice if there is a way to regenerate the last part of the URL. Is that part of the URL a generated string based on public/client side data?

Hey @TimBatist

I've just doubled checked the invitation token code, and can confirm that it is a randomly generated string on the server side.

Hello @"Justin.Yoon_1P"

That is a shame, but thank you for your answer. I think we have to try to find a way to access the user's mailbox then.

Hey @TimBatist

Yes, I can imagine that automating the manual inbox steps in provisioning can be challenging.

I've had a chat with our provisioning team that is responsible for the SCIM bridge and also the user provisioning flow over the CLI, and they've let me know that this behavior is by design, and will not change any time soon.

Hello @"Justin.Yoon_1P"

Thank you again for your answer and your time. I appreciate you for asking those teams.

It's understandable that and why this behavior is by design, but I'm wondering why this string cannot become visible when creating a new user via CLI. For example, when creating a new user using CLI (v2), I believe the secret key will be visible (as in https://1password.community/discussion/127914/op-account-add-shouldnt-show-the-secret-key).
If this is done with the secret key of the user, why wouldn't you show the generated string in the URL as well? Is this string such sensitive that it should always be hidden? But then, why can it still be sent in the email?

Hey @TimBatist

My understanding is that the randomly generated invitation token string is obscured from the inviter by design and is only intended to be accessed by the invitee, such that the invitee would be the only user who would have access to their secret key and choose their own password.

Also, just to make sure that we're on the same page - the secret key on op account add will only be visible on the local device that the user has been added to just prior to signing in, rather than it being accessed on the client/user that has confirmed the invitation.

Also regarding this:

because we use password generation instead of letting the employee choosing a probably less secure password.

I'm not sure if this fits your use-case, but do have a password policy feature in our business tier accounts as well, in which the admins can set the length, and char set requirements (letters, numbers, and symbols) to ensure that the passwords can live up to expectations.

Hey @"Justin.Yoon_1P"

Thank you for your time again.
First of all, it makes sense that the token string is obscure for the inviter. Besides that, thank you for clarifying the use case of the visible secret key, we have not tested a lot with the CLI 2.0.

Regarding the password generation, our use case is to let the invitee have as less interaction with a new device and accounts as possible. Therefor we want to automate the whole process, inclusive the part that the invitee should normally do. We would like to use memorable passwords. We are aware of the memorable password generator, but the big disadvantage we found is that there are some "weird" words in the list, like old-English words that are not really memorable for our mostly Dutch employees. Also, we would rather passwords containing words like "cancer". Therefor, we decided to use our own password generator with a custom words list.

Again, I want to thank you for your time and effort trying to help us out, but it looks like there is no detour finding the invitation token string. We will try to find a way to access the invitee's inbox to find the invitation URL.

Thank you for your time again.

Not at all, it was my pleasure. I would love to hear an update if you figure out a method that works for you.