onflow / developer-grants

Grants for developers that contribute to the broader developer ecosystem
Apache License 2.0
50 stars 18 forks source link

AuthFlow: AuthFlow is an Identity & Access Management (IAM) system secured by the Flow Blockchain #77

Closed BoiseITGuru closed 2 years ago

BoiseITGuru commented 2 years ago

AuthFlow: AuthFlow is an Identity & Access Management (IAM) system secured by the Flow Blockchain

Grant category

Please select one or more of:

Description

AuthFlow is an on-chain Identity & Access Management system and a replacement for services like Amazon’s AWS IAM or Microsoft’s Azure Active Directory, secured by the Flow Blockchain. Working in partnership with Emerald City DAO, EmeraldID will be updated to be the sole public Identity Provider for AuthFlow.

Problem statement

Current blockchain-based authentication methods typically only allow a developer to confirm who a user is and has to utilize other Web2 authentication methods and services (ex. Auth0, Okta) to do anything beyond smart contract interactions. As we move into a Web3 world there are still many use cases that require secure access to Web2 technologies. Such as accessing simple things like role-based access control to an app’s functions or a simple backend.

How it Works Today

As a developer creating an application, you want to provide secure access to your app. You allow users to log in using their Web3 Wallets, in the case of the Flow blockchain this is a multi-step process that provides you with a user identifier (Flow address) proving ownership of their on-chain account. This process is done through the FCL account proof process which provides functionality to prove a user is in control of a Flow address. All other aspects of authentication, authorization and session management are up to the application.

This current Web3 solution puts a heavy burden on the DApp developer(s) requiring them to write an extensive backend system to manage user access and authorized access to functionality.

Proposed solution

AuthFlow is an on-chain Identity & Access Management system, essentially a replacement for services like Amazon’s AWS IAM, Microsoft’s Azure Active Directory, and Auth0. Utilizing the Flow Blockchain, AuthFlow will return control of user identification and authentication to the app developer and end-users by merging Web3 with known authentication methods like JWT and OAuth 2.0.

Each app will create its own AuthSystem with an Identity Provider that can be managed by multiple AuthSystemAdmins. To ensure the integrity of the Authentication System, once the contract is deployed, all keys will be removed from the account. This prevents any future modification of the contracts that change the way the system authenticates users.

AuthFlow is THE security solution for developers and end-users operating across Web2 and Web3 spaces. The functionality can be defined as an Identity Provider and Password Manager merged into one. Your wallet interacts with Web2 as a password manager across all websites and also serves as your identity provider on Web2 and Web3.

Identity Providers

Server/Client SDKs

Impact

Let’s face it, getting authentication right is complicated and one screw-up can lead to costly data leaks. The AuthFlow SDKs allow you to secure both your front and backend resources with easy-to-use methods that will verify which roles/permissions the user has, as well as evaluate any access policies to ensure users only have access to authorized resources.

The server SDKs not only allow you to protect server-side resources but also allow you to stand up your own Identity Provider server that supports JWT, oAuth2.0, and SAML2.0 authentication methods.

Currently, The security measures that are present in Web2 authentication offered by identity providers like Auth0, Amazon’s AWS IAM, or Microsoft’s Azure Active Directory are superior to those on Web3. Not only does AuthFlow protect its user from vulnerabilities in the Web3 space, but it will also tighten user security across Web2 sites.

AuthFlow is THE security solution for developers and end-users operating across Web2 and Web3 spaces.

Milestones and funding

Milestone Deliverables Timeline Risks USD proposal
1 - Contract Completion Smart Contract containing auth-system, auth-system admin, identity provider and identity provider admin resources. Along with needed functions for Dapps to interact with the contract. 2 months - Completion within timeline. “TBD”
2 - Go (Golang) Server SDK Go Server SDK with support for oAuth2 3 months - Completion within timeline.
- Emerald Shield contract audits may require rewrites to the SDK specifications which would extended the overall project timeline.
“TBD”
3 - JS Client SDK JS Client SDK with support for server and client-only modes 3 months - Completion within timeline.
- Audits of server and client SDK’s may require rewrites to the SDK specifications which would extended the overall project timeline.
“TBD”
4 - AuthFlow Manager & EmeraldID upgrades. Hosted management UI for AuthSystem Admins to manage their roles/permissions and policies without building their own UI. 3 months - Team currently does not have a front-end developer to complete the front-end portion of this milestone, and intends to allocate a portion of funding to secure a front-end developer for the project.
- Upgrading EmeraldID to be an AuthFlow identity provider could require rewrites to the EmeraldID contract.
“TBD”
5 - Adoption & Feedback Changes Feedback period to drive adoption and iron out issues/changes from developer feedback. 6 months - Any issues, vulnerabilities discovered, or changes made from feedback could result in rewrites of all codebases “TBD”
6 - Swift Client SDK Swift Client SDK with support for server and client-only modes 3 months - Completion within timeline.
- The FCL-Swift SDK has not been completed yet and specifically does not support account proofs yet, however the FCL-Swift SDK team received a grant to complete the SDK with current timeline estimation showing completion prior to work required on the Swift SDK..
“TBD”
7 - NodeJS Server SDK NodeJS Server SDK with support for oAuth2 2 months - Completion within timeline. “TBD”
8 - SAML2.0 Support Adding SAML2.0 support to the Go and NodeJS Server SDKs and AuthFlow Manager 3 months - Completion within timeline. “TBD”
9 - Ongoing Maintenance Ongoing Maintenance and support for the SDKs 1 year - Completion within timeline. “TBD”

Team

Name Role Bio Contact
Brian Pistone Executive Team (Founder / Full-Stack Developer / Lead Engineer / Chief IT Guru) With 2+ decades in IT/software development Brian has been successfully running an IT Managed Services Company since 2017.

His life long mission of helping businesses grow through the better use of technology has lead to him becoming proficient in PHP, NodeJS/JS, Swift, Go, and now Cadence.
brian@eurekadao.io
Ashton Mercer Executive Team (Chief Development Guru) Ashton has spent the past four years studying marketing and entrepreneurial management at Boise State University, his knowledge and expertise on startup's and new venture creation is crucial to the developmental success of AuthFlow. ashton@eurekadao.io
Jordan Roeske Executive Team (Chief Legal Guru) Jordan is a licensed Attorney operating in multiple states, who enjoys and excels at legal research. Jordan provides the AuthFlow team with necessary legal guidance as AuthFlow expands into unseen territories. jordan@eurekadao.io
Andrew Van Dyke Executive Team (Chief Financial Guru) Andrew is a financial advisor and strategist with expansive knowledge of financial markets and regulations. Andrew offers financial/accounting expertise and oversee's AuthFlows finances. andrew@eurekadao.io
Jacob Tucker Cadence Developer / Emerald ID Manager Jacob (aka God) was founder of the first DAO on the Flow Blockchain (Emerald City DAO) and needs no introduction in this space. jacobtucker818@gmail.com
alxflw commented 2 years ago

thanks for the submission @BoiseITGuru. could you also add the USD proposal to each milestone for our review? thanks!

chandanworkacct commented 2 years ago

Few questions:

  1. How do you solve privacy concerns of end-users?
  2. How do you solve privacy concerns of dapps? Not all dapps want to expose their user-base on a public blockchain.
  3. How do you comply with regulations such as GDPR?
BoiseITGuru commented 2 years ago

thanks for the submission @BoiseITGuru. could you also add the USD proposal to each milestone for our review? thanks!

@alxflw Certainly!, when we originally copied the issue template it still had the option for leaving them TBD to allow your team to proposal amounts. I have a meeting with the rest of the team tomorrow afternoon, we will discuss this and will get back to you ASAP.

Few questions:

  1. How do you solve privacy concerns of end-users?
  2. How do you solve privacy concerns of dapps? Not all dapps want to expose their user-base on a public blockchain.
  3. How do you comply with regulations such as GDPR?

@chandanworkacct 1 & 2. We are using String/Password-Based Asymmetric Key Derivation to encrypt data at the Identity Provider level, depending on what type of data is used the strings or "passwords" used to created the keys are generated using one or more unique salts from either the dapp and/or the Identity Provider. For example your reference in question 2 to dapps not wanting to expose their user-base to the public; Any specific identifiers to the dapp or end user would be stored as an encrypted string on-chain, requiring you to know the encrypted value of the dapp and end-users identifiers to search for the users account public resource capability for that auth-system, to then decrypt their user data accessing their roles and permissions. In the case of logging in the end user this encryption and decryption or as I like to think of it "data translation" is handled by the Identity Provider and our sdks during the account-proof verification process.

  1. Since all on-chain user data used/generated by AuthFlow is encrypted and with the exception of previously mentioned encrypted identifiers data is stored in a resource in the end users account, almost all of the regulatory requirements would still fall to the dapp itself. However, our SDKs will have a function for the dapp to notify the Identity Provider they have received and completed a "right to be forgotten" request thus removing all identifiers from the Identity Provider to ensure compliance. We are also exploring options for using and monitoring for Flow Events through a removal request to punish, remove, or take some other actions against a dapp not complying with requests for removal.
chrisackermann commented 2 years ago

Hi @BoiseITGuru!

Thanks for your previous responses the additional details - have 2 follow up questions for you:

  1. Have you been able to frame out the USD amounts for each of the proposed milestones?
  2. We'd love to better understand what an MVP would look like for this solution. Given this size of this project, it would be helpful to understand how we can iterate upon landing an MVP.
chrisackermann commented 2 years ago

Hi @BoiseITGuru - just wanted to follow up again on the two questions above so that we can push the review of this proposal forward, thanks!

chrisackermann commented 2 years ago

Hi @BoiseITGuru - I'm going to close this issue out for now, but please feel free to re-open if/when you're ready to dive back in. Thanks!