Expanding VivoKey Spark's usage to the broader web

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 - https://github.com/IdentityPython/SATOSA. 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.

&state=[redacted state ID].account-console
&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!



Looks like you haven’t allowed redirections to that site (a security feature to prevent attackers to steal the token by redirecting to their site.)
So in you keycloak you’ll find a redirection URI somewhere (I think in the client settings) and you should check that the value there matches redirect_uri from the request,.
Not too familiar with Keycloak, but you’ll find it.
Idk if its just https://domain or you need the path or only the domain, play with it you’ll figure it out…
To test it you can put a * there, but you need to figure this out, * is insecure.

I’m not entirely sure what you mean by that, I actually do not control the URI for the OIDC redirection URL. for example, when configuring Vivokey as an Identity Provider, it provides the redirection URL.

The redirect URI is then entered into the Custom Application section in the VivoKey app as the Redirect URL. Then the ID and Secret are loaded up into Keycloak.

all endpoint values were configured automatically by https://api.vivokey.com/openid/.well-known/openid-configuration

You can generate a valid OIDC request using the openidconnect.net playground to test out VivoKey OIDC. Create a custom app in the VivoKey app with callback to https://openidconnect.net/callback and fill in the OIDC Client ID and OIDC Client Secret and use https://api.vivokey.com/openid/.well-known/openid-configuration as Discovery Document URL and you should be presented with VivoKey login

FACEPALM :man_facepalming:

Changing the OIDC callback URL in the Vivokey app also changes the ID (but not the secret). I had the wrong ID in Keycloak. Once updated, I was just able to validate a request to from Keycloak to Vivokey. Hooray!

Now im moving on to streamlining the keycloak login to always default redirect to OIDC, and then I will begin integrating Google with it.


Very interesting.

Can Vivokey managers provide a detailed guide to set it up?

What should you do if you have a private non paid google account for private apps, and a separate paid google business account, for work needs?

1 Like

This kind of integration only works for Google Workspace accounts. It will not work for a personal gmail.com account. I have always had a personal custom email account that I have used for work, freelancing, etc. I eventually moved it over to Google Workspace so I could use Gmail, and having drive and everything else was a nice benefit, especially for about $8/month.

If you have a web domain that you use for personal/fun stuff, and are holding on to it, I recommend setting up a single user Google Workspace and migrating over to it. Access to drive, gmail, and everything else Google. Plus, I often use mine to sign in to other websites, using the Sign in with Google button (which I am now forwarding to my VivoKey)

Well, this is pretty sick! I got the whole thing working.

I am now using my VivoKey Spark to cryptographically authenticate to all Google services. Any website that has a sign in with Google button is now accessible through my VivoKey.

I’m stoked to use this more! To my knowledge, nobody has done this before with their Spark (or at least, documented it and posted it) and it majorly opens the door to use my implant for it’s intended purpose!

I will be writing up a detailed how-to guide soon, as well as testing other services than Keycloak (Jumpcloud/Okta/Auth0 developer tiers) This will all be posted in the VivoKey Forum, probably not the Dangerous Things forum we are on now. If you have a VivoKey Spark, you should definitely set up your profile and check out the forum! - https://members.vivokey.com/ (you can use your Vivokey to sign in/register for the forum :wink: )


This is legendary.
This will be the solution until all sites have provider independed passwordless login, or VivoKey forked every service there is.
Amazing work, I’m super tempted to buy a Spark now… you’ve increased it’s value a LOOOT.

On the other hand, google is now actually tracking you with a microchip…


Nice work!

Let me just ping our software lead @fraggersparks

Okay just thinking loud how to automate that for users.
Couldn’t VivoKey make a “Company” on google where we’re all sperate users? Can it be set up so we “dont see each other”?
Then we could all have a user@vivokey.com email for Sign in with Google… paying our monthly fees for the google account.

Could you migrate existing accounts to that? Can you maybe add existing emails as main email on those Google accounts?

I think this is something that should be evaluated. I ordered a Spark test card, I wanna set this up aswell.

The other option would be making the setup much easier.
I guess your post in the VK forum will be extremely helpful, but I guess with a Docker image and like a setup script that talks to VK for setup it would be a lot easier. Even not very technical people can get Digital Ocean droptlet and run a guided install script.

Since this probably stays the exact same process for the Apex this is probably now one of the top use cases of implants, it should be as easy as possible.


I have been thinking about this, and I do think there’s some value in having a few managed services helping biohackers get more out of their stuff. I am going to be exploring this idea once I write up a tutorial and such.

VivoKey as a company wouldn’t even need to do this, Platforms like Google Workspace, Dropbox, etc usually have “tenant” functions, basically separated out. It would be pretty possible to build out a semi-managed service offering these kind of things for a monthly fee, and the overhead is incredibly minimal.

I am looking into other options than just Keycloak. Plenty of people can set up a digital ocean instance, get a DNS registry, and run a container, but not everybody. For maximum accessibility, I would like to have the option for users to be able to use this stuff without having to know any of the hosting-level skillsets. This is why I am looking into Auth0 and Okta, as these platforms all have free developer tiers, and you won’t have to worry about paying a bill, registering a domain, handling TLS, etc.

I think it’s really fun to have these kind of projects and do selfhosting, and I think the usage of open source software and running services yourself is pivotal to the (bio)hacker mindset. However, on the flip side, it is too easy to hack together some project that lives for a few months, maybe a year. When it comes to the very core of my digital identity, and the authentication/authorization into that space, I want something more infallible; longevity is incredibly important. (also, you don’t want to get locked out of every account in the world because you forgot to renew a domain or something)

Also thinking out loud, the VivoKey Connect API recently added Key/Value services. I haven’t looked at it much, but from my understanding, you could build an entire platform around not just authenticating access, but also encrypting every user’s data with the user’s keys. Obviously this would be pretty custom built, or at the bare minimum, require some wrapping/sidecar development. I could see a Hashicorp Vault-like that encrypts all of your personal data at rest, using your own keys. This would be user-specific, and I believe would also allow a user to completely disconnect a third party service from having access to their data, since it is individually encrypted.


Who’s developed the app for the Vivokey? in all of my testing I have generated a lot of requests, and have documented some really buggy behavior.

For instance, it constantly decides to not accept the chip tap, and instead, opens my profile page (even though I have set the chip settings to do nothing on scan).

It’s getting incredibly annoying, and honestly breaks all the time. The app has some serious issues with interacting with the chip vs the phone just picking it up as a tag.


You probably need to speak to @fraggersparks and @RyuuzakiJulio

Darf ich Fragen ob es Android oder IOS ?
Habe die gleichen Probleme mit I Phone XS IOS 14.8 . Habe keine Einstellungen vorgenommen . Alles Werkseinstellung.

Vault? You mean Ansible Vault surely. :innocent:

Actually I find it interesting that you can tell a bit about people’s backgrounds by the comparisons that they make.

No, I meant what I said; Hashicorp Vault - https://www.vaultproject.io/

Ansible, and Ansible Vault really do not have any relevancy to what I am referring to.

Man, no sense of humour…

Hashicorp Vault and Ansible Vault provide very similar functionality. The only real difference is that Hashicorp Vault has an api. Nike developed Cerberus with a very similar idea in mind.

My real point was that Vault as a name is unfortunately used by too many people for similar products (Vivokey vault). (Cerberus/Kerberos is another similar problem).

Hello Pips.

I see you are having some issues with an app. And would like more information about your experience with the app on your device.

If you are referring to the iOS VivoKey app.
I created the iOS side VivoKey app.

What do you mean by “generated a lot of requests”?
Do you mean API calls to the server request? or submitted crash or bug requests somewhere (i.e. Apple)?

You have documented some buggy behavior.
Where can we see this documented behavior?

“It decides not to accept the chip tap” Who makes this decision? The app decides to deny a chip scan? Does it cancel as in a time-out? Or is the device decides to reject a NFC scan?

“and instead, opens my profile page” So is it accepting the NFC Scan? What do you mean by “decides not to accept the chip tap”? What takes you to a profile page? The device? The app?

“Breaks all the time” what exactly is breaking, the interface, is it a full on crash, colors? knowing exactly what and when it happens would help to find a possible reason and a solution.

“serious issues with interacting with the chip” Can you specify what are this issues when NFC Scan interaction and when are they occurring?

“vs the phone just picking it up as a tag” How does the phone picks it up as a tag? Does your phone’s VivoKey App identifies the NFC chip as something else than a tag?

I’m very curious to what is your experiences with the app.
Would also like to know what device model you are using the VivoKey App in.

Look forward to your answers.


I moved this to DMs, check my message for my full bug report. Thanks!

Windows Hello aims to eliminate the need for passwords after it is set.
I have never researched it in depth enough, but it has options that make use of the chips.
After a few basic settings, you can see how I am loging in to my Facebook account, or Gmail account. after reading the chip, it confirms to Windows Hello to enter a saved password.

It works on Edge, i do have some paid MS work account.
I didnt manage to set up the sync option yet.


from superficial reading, it may be possible to enable Windows Hello functions in Chrome.

1 Like