OAuth 2.0 authorization using blockchain-based tokens Nikos - PowerPoint PPT Presentation

OAuth 2.0 authorization using blockchain-based tokens Nikos Fotiou, Iakovos Pittaras, Vasilios A. Siris, Spyros Voulgaris, George C. Polyzos

Resource sharing Authorization Client Resource owner Resource storage Resource access Resource server

OAuth 2.0-based authorization Client Resource owner Authorization request Authorization grant

OAuth 2.0-based authorization Client Resource owner Authorization request Authorization grant Authorization server Authorization grant Access token

OAuth 2.0-based authorization Client Resource owner Authorization request Authorization grant Authorization server Authorization grant Access token Resource server Resource request, token Resource

Our work Client Resource owner Authorization request Authorization grant Authorization server Authorization grant Access token Resource server Resource request, token Resource

The Ethereum blockchain • Data “recorded” in the ledger are immutable • Decentrilized “smart contract” can be executed by untrusted nodes in a deterministic way

ERC-721 ERC-721 tokens • Token Id • Owner Id • Metadata

ERC-721 ERC-721 tokens ERC-721 token management • Token Id contract • Owner Id • ownerOf() • Metadata • transferFrom() • tokenURI() • approve() • getApproved()

JWT { Client “iss”: Authorization Server “aud”: Resource URI “sub”: Client Key “exp”: Expiration Time “jti” : Token identifier } Authorization server Access token

JWT + ERC-721 { Client “iss”: Authorization Server “aud”: Resource URI “sub”: Client Key “exp”: Expiration Time “jti” : Token identifier } Authorization server ERC-721 token Access token Token Id : jti Owner Id : Client key Metadata: JWT

Accessing legacy resource servers Client Resource server Resource request, token Verify Client key ownership Resource • It facilitates logging and auditing services • Clients can at any time retrieve their access token from the blockchain

Accessing resource servers with BC read access Client Resource server Resource request, token ownerOf(), tokenURI() Verify Client key ownership Resource

Revocation Authorization server Client Resource server transferFrom() Resource request, token ownerOf(), tokenURI() • Revocation is asynchronous • Authorization server does not have to be online

Delegation Client A Approve(Client B) Client B Resource server Resource request, token getApproved(), tokenURI() Verify Client key ownership Resource • Delegation is not transitive • Revocation is not affected

Fair exchange Client Authorization server ERC-721 token Access token Token identifier Owner : Authorization server Metadata: JWT Payment transferFrom()

Discussion • Existing OAuth 2.0 code-base can be re-used • In some cases our approach is transparent to OAuth endpoints • In no payments are involved then private, or testing chains can be used. • If the client does not interact with the blockchain, then ownerOf() may return any type of identifier. • (Public) blockchains have privacy issues, introduce delays (~13sec per transaction) and monetary costs (~$0.10 to create a token, $0.02 to revoke or delegate)

Thank you fotiou@aueb.gr https://mm.aueb.gr/blockchains