How is the provisioning invitation URL generated?
Hello there,
We are testing with automating the creation of new users in 1Password. We want to use either the SCIM bridge or the CLI to invite users. The invite mail the user receives is more or less the same, and so does the URL in that mail. The structure looks simple: https://{ACCOUNT}.1password.com/provision/{USER_ID}/{SOME SORT OF STRING}.
We also want to automate the full process of account creation, including setting up the account with a password for the user. Therefore, we want to know what that "SOME SORT OF STRING" is and how we can reproduce it. If that is not possible, we might need to access the mail account of the new user and extracting the URL from the mail.
Does anybody know what that "SOME SORT OF STRING" in the URL is?
Thank you in advance.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Comments
-
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.
0 -
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?
0 -
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.
0 -
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.
0 -
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.
0 -
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?0 -
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 addwill 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.
0 -
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.
0 -
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.
0
