Category: identity

Decentralized Identity Based on Blockchain

· Leave a comment ·

Sovrin project. Uses a Permissioned blockchain which allows it to do away with mining as an incentive and instead directly build a Distributed Ledger Technology which stores Distributed Identifiers (DIDs) and maps them to claims. Removal of mining frees up resources and increases network throughput. Interesting Key Management aspects, including revocation. Contrasts with Ethereum uPort – which is permissionless and public. Neat design, but will face adoption problem as it is unhitched from bitcoin/ethereum.

Click to access Sovrin–digital-identities-in-the-blockchain-era.pdf

Click to access The-Technical-Foundations-of-Sovrin.pdf

DPKI – Distributed PKI. Attempts to do reduce the weakness of a centralized certificate authority as compromising that cert authority affects each of its issued certificates. This concept is built out and used in Sovrin. https://danubetech.com/download/dpki.pdf

Remme. Remember me. An approach to SSL based logins. Modifies SSL.
Used an EmerCoin implementation as mvp and Ethereum blockchain. EmerCoin: https://emercoin.com/content/EMCSSL.pdf . Adoption problem here is change in behavior of each browser and mobile app. https://medium.com/@alexandermomot/passwords-are-crap-6ed4e97bffa7

Sidechains. Original proposal was to free up resources for when trust is established, to reuse blockchain technology and to establish a two-way peg between the sidechain and the blockchain. https://www.blockstream.com/sidechains.pdf
https://bitcoin.stackexchange.com/questions/32367/mining-on-pegged-side-chains

Coco Framework. https://github.com/Azure/coco-framework

HyperLedger – Linux based framework for developing blockchains software. Provides a DLT and uses Intel SGS extensions. (Intel+Microsoft+Linux foundation). Uses a replicated state machine model with each validating peer independently adding to its chain after reaching consensus on order of txns with other peers using Practical Byzantine Fault Tolerance or Proof of Elapsed Time. https://software.intel.com/en-us/blogs/2017/08/10/collaborating-with-microsoft-to-strengthen-enterprise-blockchains . Related – https://stackoverflow.com/questions/36844827/are-blocks-mined-in-hyperledger

A comparison link – https://stackoverflow.com/questions/41690983/different-between-various-blockchain-protocols

 

SSO, SAML, OAuth, JWT, OpenID

· Leave a comment ·

Web authentication and SSO typically imply that state is maintained on the server to indicate whether the user is logged in or not. The identity provider maintains this state and the identity consumers check this state with the identity provider. The protocol and message format differ in different implementations – SAML, OAuth, OpenID and several others.

SAML is the richest, most flexible auth protocol, but also most complex to implement. It covers the most number of use cases. The security assertions about an identity are captured in an xml format which can be exchanged between providers and consumers over the web.

OAuth is simpler and requires fewer things from the implementer. OAuth 2 has become a vehicle for enterprise use cases like SAML. SDKs for OAuth are available.

OAuth 2 and OpenID both use Json WebToken (JWT) which is a JSON format specification for interoperability.

OpenID Connect is the most open and newest of the three. It reduces  reliance on checking auth state with the identity provider by embedding more information in the JWT and standardizing things like scope to increase interoperability. If officially supports authentication use cases, unlike OAuth2 which is designed for authorization, but is used for pseudo-authentication.

A key consideration when deciding on an implementation is the scalability requirement. Ideally the system is structured to keep the least amount of state (zero) on the server. This is not true of most SSO implementations.

Like a stateless NFS server, based on leases for lock state that can be refreshed, a stateless implementation for SSO is possible (classic NFS has no open, only lookup). The tradeoff is that revocation is not as easy and reporting may need to be handled differently than with a stateful implementation. Here’s a discussion – http://stackoverflow.com/questions/26739167/jwt-json-web-token-automatic-prolongation-of-expiration

Update. Here’s another discussion which points to some tradeoffs – https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-session-tokens , basically that this is more useful for SSO and API implementations not simple websites.