Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't include issuer in URI path when it is included as a parameter #47

Closed
wants to merge 1 commit into from

Conversation

dapphp
Copy link

@dapphp dapphp commented May 6, 2016

I noticed when testing with QR codes that Google Authenticator doesn't recognize the issuer when the otpauth://totp/Issuer:Label?secret=1234 scheme is used and it instead needs to be otpauth://totp/Label?secret=1234&issuer=Issuer.

This minor change makes it so if the isIssuerIncludedAsParameter() property is true, the path component won't get the issuer, and instead it will be a query parameter as is already the case.

Feel free to merge if this change makes sense overall.

@dapphp
Copy link
Author

dapphp commented May 6, 2016

Guess I didn't do full due diligence on this before. FreeOTP Authenticator doesn't recognize the issuer query parameter and Google Authenticator will apparently ignore the label part if the issuer there matches the query string parameter.

So:

otpauth://totp/Issuer:Label?secret=xxx works fine in FreeOTP Authenticator, Google Authenticator shows no issuer and the label is "Issuer:Label"
otpauth://totp/Label?secret=xxx&issuer=Issuer Fine in Google Authenticator, but no issuer appears in FreeOTP
otpauth://totp/Issuer:Label?secret=xxx&issuer=Issuer Fine in both, and Google Authenticator doesn't show "Issuer:Label" as the label when it is present in query string.

@dapphp dapphp closed this May 6, 2016
@Spomky
Copy link
Member

Spomky commented May 6, 2016

The problem with the provisioning uri is that it is not part of the RFCs.
This part of the project is mostly based on user/developer experiences or application documentations, but not on a RFC or specification.
This means that each application is free to decide the information to store and use its own template.
Even Google Authenticator has a different behavior depending on the platform (Android or iOS).

Have you tried to use '%3a' instead of ':' to separate the label and the issuer? Some applications use this separator (I don't remember how Google Authenticator works).

@dapphp
Copy link
Author

dapphp commented May 6, 2016

In my application I am using %3a to separate the issuer from the label. Without the issuer in the query string, Google Authenticator showed the label as My Company:Their Label (with the colon separator), but when I put the issuer in the path and the query string, it shows up as expected in the app with issuer separate from label.

So for compatibility with at least Google Authenticator and FreeOTP authenticator, I am now including the issuer in both places (query string and path). Both seem to be happy with it now.

@Spomky
Copy link
Member

Spomky commented May 6, 2016

OK thanks for the information.
I think I will add a section in the documentation on this topic.

@dapphp
Copy link
Author

dapphp commented May 9, 2016

Found this which may be helpful when documenting: https://github.com/google/google-authenticator/wiki/Key-Uri-Format

Specifically,

Older Google Authenticator implementations ignore the issuer parameter and rely upon the issuer label prefix to disambiguate accounts. Newer implementations will use the issuer parameter for internal disambiguation, it will not be displayed to the user. We recommend using both issuer label prefix and issuer parameter together to safely support both old and new Google Authenticator versions.

Which explains why I could only get labels working in multiple apps using both label and query string parameter.

@Spomky
Copy link
Member

Spomky commented May 10, 2016

Please update the library.
Now the issuer is set by default as a query parameter and as a label prefix.
The documentation is also up to date.

Thanks.

@Spomky
Copy link
Member

Spomky commented May 10, 2016

Tagged v7.0.4

Spomky pushed a commit that referenced this pull request Jul 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants