Just a question about getting a “shared secret” for some HOTP display cards I’ve already imported into PI.(imported from a seed file)
in Okta’s API you can use a “custom OTP” as a factor, but the enrollment on the okta side is wanting a either hex,base32 secret key to be used in it’s “enroll user factor” api
do I need to generate this shared secret from the PI API? or am I completely missing the mark here?
If you have hardware tokens that have been imported, the will find the secret in the import file.
There is no way to extract the secret from privacyIDEA.
So you will have to take the secret from the import file.
Note: You say you are importing HOTP. Okta claims to support TOTP. This will not work out.
TLDR: okta documentation is getting me mixed up here…
correction, I have token2 display cards that have a seed file generated from the company and imported into PI as TOTP tokens… okta likes to jump between hotp and totp in their documentation …, the use of custom OTP as a factor has alll sorts of different labels in their documentation?
the damn documentation there goes from token:hotp to TOTP…
yet they state both are supported?
trying to get okta support to tell me what is needed to just use PI as a validation endpoint has been a trip…
yet the biggest thing that is throwing me off here is the requirement for that shared secret? Okta support tells me it needs to be something that okta api uses to “connect” to PI for the factor’s interaction? the documentation lists the shared secret as a " Unique secret key for prover "?
as for the secret in the seed file, I had used the option for " CSV for PrivacyIdea" on the token2 website. which has like just 5 commas separating the serial, seed?, type, otp-length, and time shift.
is the “seed” the secret okta is asking for? and if soo… do I need to encode it first? (base32 or 64, they also have HEX as an option when adding the factor to okta).
otherwise, I appreciate all the help, and my advanced apologies for my ignorance on this subject.
