The JS API returns a ‘raw’ signature, whereas OTP’s :public_key API expects a DER-encoded signature.

Try this:

message = "abc"

encoded_signature = "AOqjfvb1P0fYdbnq+f3XsbOR/Lylq4csC5e1Ks4cKRTcWKQyH4CVr/XRHCmZDEWOpaA8gwuM3Z3qD21vMaixySUPASTDnd1J8shNx51MCbONIReTNuH53kzxykLpf0riSyMbEBQtie4/pxlrolUOsDja2f/ikgM/lGXtCTXz2faV4m2Y"

public_PEM = "-----BEGIN PUBLIC KEY-----
MIGbMBAGByqGSM49AgEGBSuBBAAjA4GGAAQB7PNQVbADLNyobtijE5NVZUvHs74h
iMntCbp0C8pdU1IQRWlAfDeEs/iuxA32VARw9Q5/0mim8Si8JcpCJnhS0u8AESMf
Ux3WqzHhB33t4q3iPsJbM7zmN91QNnbYErrGqEDCmSruPpKw1iK5dJ3/xQZbkpmR
ztoVwrZoCoGUu+WTqEI=
-----END PUBLIC KEY-----"

raw_signature = Base.decode64!(encoded_signature)
size = div(byte_size(raw_signature), 2)
<<r::binary-size(size), s::binary-size(size)>> = raw_signature
signature = <<48, 129, 136, 2, size, r::binary, 2, size, s::binary>>

[key_entry] = :public_key.pem_decode(public_PEM)
public_key = :public_key.pem_entry_decode(key_entry)

:public_key.verify(
  message,
  :sha256,
  signature,
  public_key
)
# returns true

To clean up that code, here’s a module that can help convert from raw format to DER format using :public_key:

I might add it to x509 at some point…

Thanks for this. So to use the functions bellow I would use?

signature = ECDSASignature.new(raw_signature) |>ECDSASignature.to_der()

Also does the :public_key module not expect DER encoding for RSA keys? My original code seams to work for rsa signatures

I am curious to know what are you trying to achieve with this approach of sending the signature in the authorization header of a request?

Correct

An RSA signature is just a single integer, which is simply encoded as a binary by all implementations. An ECDSA signature consists of two integers. Some implementations wrap those in an ASN.1 ‘Sequence’ and others just concatenate them (which may require zero-padding of the smaller of the two, to remove ambiguity about where to split).

Just some experiments at the moment, but in general i’m looking at alternatives to passwords

Client side generated secrets can be reverse engineered in mobile apps, that ship their code obfuscated in binaries, and in the web is even more easy to reverse engineer this process, thus anything generated programmatically in the client side cannot be trusted for authentication purposes.

What about Crypto.getRandomValues()?

Sorry I was not meaning the code used to generate the secret… What I was trying to say is that any secret generated in the client side can be reused by an automated script to access the backend as the genuine web app or mobile app.

Another approach is that the automated script can use the same code of your app to generate the authorization secret, thus your backend will trust in requests from automated bots, when you want it to only trust in requests from your genuine web app or mobile app.

Ahh I think I see. I don’t think I have any problems with people using their own client to access my API, if they want to go to that effort