1D/ Better and more secure methods for API authentication

From IIW

Better and More Secure Methods for API Authentication

Tuesday 1D

Convener: Michael Lodder

Notes-taker(s): Jan Christoph Ebersbach

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: 

Presentation slides: https://docs.google.com/presentation/d/1UO25DzVmq25ya2S4_tV5UKTSP6NtBggln9vP1TEXSzE/edit

Goal of the Oberon protocol when building an API:

  • Super effective: no separate session token to required for accessing the API; very fast to issue and verify tokens; 128 bytes required per message

  • Privacy preserving

  • No new crypto, uses BLS signature keys and Pointecheval saunders Construction

Questions:

  • Can multiple tokens can be combined: Michael: yes, that’s possible.

  • Will the implementation become open source software: Michael: yes, that’s planned.

  • Can a proof be reused for API requests? Michael: yes, within a certain time frame it might make sense. However, the idea is to generate a new proof for every request. Proof generation is very simple so that even low powered devices can do it without much effort. Verification of the proof takes longer than proof generation.

  • Use cases? Michael: HTTP API authentication and potentially even did:peer; 2 IoT devices that have never talked to each other before shall be able to authenticate each others tokens and establish a secure connection.

  • Quantum resistant? Michael: no, it’s not. Post-quantum resistance would require very large keys in the range of kilobytes.

  • What’s the performance of the solution? Tobias Looker points out that the performance varies greatly depending on the environment the code is executed in. Mattr did performance comparisons between native node modules, WASM and ASM.js, more at: https://github.com/mattrglobal/bbs-signatures

  • Differences to OAuth? Phil: People today use long lived tokens for OAuth. These tokens/secrets are known to both parties, the developer and the server. Whoever gets their hands on the tokens will have full access to the API. With Oberon, the secret is only known to the developer which protects them more.

Retrieved from "https://iiw.idcommons.net/index.php?title=1D/_Better_and_more_secure_methods_for_API_authentication&oldid=23671"