Alternate User Authentication method in Canister

Maybe this will help you.

I have open sourced my project where I implemented it by calculating a JWT in Python, pyJwt, using an off IC Django API. It is bit elaborate, but it does nicely secure things using II.

  • The live deployment of my project can be found at

  • The full application consists of 3 GitHub repositories:

  1. dapp-0
  2. dapp-0-django
  3. dapp-0-bot

I am considering to sponsor a bounty with icdevs to for someone to implement the equivalent of pyjwt in Motoko. That would make things more easy.


I appreciate your solution very much, and please try to get it listed in GitHub - dfinity/awesome-dfinity: A curated list of awesome projects and resources relating to DFINITY and the Internet Computer

Just a note:

With the upcoming threshold ECDSA feature, you can also issue JWTs using asymmetric cryptography without having to store secrets in a canister.

If anyone is interested in implementing tooling and an example application please talk to me.


Am interested, lot of vital application for on-boarding with this kind of functionality.

I think that would be a really helpful example - threshold ECDSA is going to be a really versatile feature, and we should be hyping it up more for general secret functionality

@domwoe ,
I am very interested to learn how one could get a JWT.

It would simplify my app architecture a lot.

Where can I learn more about it?

Hey @ArjaanBuijk,

I’d love to get more input on your use case.

Do you want to use a canister to issue tokens that can be used to access resources outside the Internet Computer?

Yes, exactly!

I am using a chatbot framework that runs outside the IC, in a traditional cloud. Long term my goal is to run it on the IC, but that will be long term.

My front end is serbed from a canister and it uses Internet Identity as the login mechanism. After login, he frontend then connects to the off IC chatbot over socketio, protected by a JWT token.

Ideally, as part of the Internet Identity login flow, an asymmetric JWT would be generated in the canister and returned to the frontend, which then uses that to authenticate with the chatbot.

Currently, I hacked together an elaborate procedure where the front first logs in with II, then calls an api of an off IC python web server to generate the JWT. The python webserver calls a canister to confirm that a principal was properly logged in with II, and only if that is the case, will it return a JWT. Currently I am using a symmetric JWT and store a secret with the python server that generates the JWT and with the chatbot that validates the JWT.

That off IC python server and complicated logic, just to generate a JWT can be removed if the JWT could be created by the canister during II login.

Please let me know if my description is clear.

Thank you for the description.

I think your architecture is not a bad choice.

You could also verify the delegation from II directly on the chatbot server and just create a session for the user.

tECDSA signatures for access tokens are probably too costly/resource intensive (currently a subnet can do about 1 sig/s). Nevertheless, I created a small PoC that creates different types of JWTs on the IC, if you’re curious:


Thank you for that feedback and the example.

I like your idea to verify the delegation from II directly on the chatbot server and just create a session for the user. I am going to investigate that option.

The complication is that you’d need to verify a canister signature.

Here’s the respective code in the replica: ic/ at 4c6487b6c0bd53fe1973c7d88cc4d30b90e1dd35 · dfinity/ic · GitHub

cc: @rckprtr