Hi all, I am working on connecting VivoKey Connect (the OIDC platform for the Spark) to allow me to use my VivoKey Spark to sign in to my standard accounts; gmail, youtube, etc.
I posted a thread in the Vivokey community, but I thought I might cross post here as well, if that’s okay. (feel free to delete this post if that’s not allowed.)
My current goal is to target the “Sign In with Google” option that is present with most websites, and make it redirect authentication to VivoKey Connect. In my mind, this would be the most broadly integrated Identity Provider to target across the web, as nearly every website allows this option, while virtually no web service allows you to specify an OIDC endpoint for IdP. Even if you could make X site point at an OIDC endpoint, the functionality and integration would have to be replicated across every platform.
If you have a paid Google Workspace account, you have the option to have your Google Workspace authenticate to a third-party Identity Provider. Companies often use this to tie in their directory service with all of their apps, such as Okta, Auth0, Active Directory, etc.
This seems like a solid way to use your VivoKey Spark to log you in to your everyday apps. You click the Sign in with Google button, which redirects you to the Google Accounts sign in page. From there, you would click the Google Workspace account, and google would forward you on to VivoKey for account authorization. Tap your implant, and you have successfully signed into your Google account, which then signs you into every website that allows that login method.
Unfortunately, Google only supports SAML as a third party Identity Provider, and provides no support for an OIDC endpoint.
So, armed with this knowledge and issue, it seems that there needs to be some kind of middle-man proxy/brokerage service, that sits in-between Google and VivoKey. This proxy service would run a SAML IdP service that Google is pointed to, then it would translate the request and become an OIDC Client, then creating and forwarding a request to the VivoKey Connect OIDC endpoint.
I have come across a couple of tools that might enable this brokering service.
The first tool is SATOSA - GitHub - IdentityPython/SATOSA: Proxy translating between different authentication protocols (SAML2, OpenID Connect and OAuth2). This tool is effectively an IdP proxy, that can be configured in many different ways. It can do SAML ↔ SAML, SAML ↔ OIDC, and preform assertion translations in the middle to make sure that the proper data is passed back and fourth between applications. This seems like a good solution, however, SATOSA is incredibly complex and can be used in many different ways.
The second tool that might fill this void is Keycloak - https://www.keycloak.org/
The documentation on Identity Brokering can be found here, which is where I pulled the image for the authentication diagram. To me, this seems like the most probable solution to use, and also provides a powerful web UI for managing users (since it is a full fledged Identity Provider service like Okta)
I will keep this space updated with my progress on trying to enable VivoKey across the web using Sign in with Google.
I currently have a Keycloak server set up and running. I have configured it to point at the VivoKey Connect OIDC endpoints, using the https://api.vivokey.com/openid/.well-known/openid-configuration to pre-fill all elements of the OIDC connection. I have a custom app in the VivoKey app, with the callback URL set to the OIDC endpoint in Keycloak and the Client ID/Secret loaded into Keycloak. I also set up the openid, profile, email assertions to make sure it grabs user data from Vivokey.
However, I cannot seem to get the authentication request to validate with VivoKey. No matter the body of the request or any configuration changes I make, https://api.vivokey.com/openid/authorize fails to accept the request, stating that The request fails due to a missing, invalid, or mismatching redirection URI (redirect_uri). There is no more information than that, and the URI and the rest of the request look okay to me. Maybe @amal could help me figure out what is going wrong with the way Keycloak is generating it’s request.
Here is a sample of the request, with redacted values.
https://api.vivokey.com/openid/authorize
?scope=openid+profile+email
&state=[redacted state ID].account-console
&response_type=code
&client_id=[redacted client ID]
&redirect_uri=https%3A%2F%2F[redacted domain]%2Fauth%2Frealms%2Fvivokey%2Fbroker%2Foidc%2Fendpoint
&nonce=[redacted nonce]
Sorry for the long post! If anyone has more experience with OIDC/SAML as a protocol, and implementing/debugging IdPs with all of their quirks, I would love to chat!
<3
)