Skip to content
Snippets Groups Projects
Commit 62bc5d10 authored by Gospodin Bodurov's avatar Gospodin Bodurov
Browse files

Workflow documentation

parent eae1eb00
No related branches found
No related tags found
No related merge requests found
Pipeline #16347 passed with stage
Stage:
    in 8 minutes and 49 seconds
    Hide whitespace changes
    Inline Side-by-side
    Showing
    with 117 additions and 0 deletions
    README.md
    + 117
    − 0
    View file @ 62bc5d10
    # Vereign mobile application.
    The idea behind Vereign mobile app is to provide access to our Dashboard app via WebView and to give ability to 3rd party mobile applications to gain access to our restful-api via Oauth2 protocol. We are using app links to communicate between 3rd Party App, Vereign Auth App and Browser via GET protocol.
    # Security Concerns
    App links usually creates internal "Internet" network in the User Device, but still apps can not use https for communication, which could lead to lack of authenticity and privacy in that communication. IETF suggests to have random generated token sent to Oauth2 server and secret keys to be stored in 3rd Party App server.
    # Improved Security Scheme
    Better approach is to use Public(Certificates)/Private keys encryption scheme where private keys are stored in both Vereign and 3rd Party App servers. Vereign Auth App generates Symmetric Key for every auth request coming from 3rd Party App and encrypts the Symmetric Key with Vereign Server Certificate. Later Vereign server will decrypt 3rd Party App Return Link and will encrypt it with the Symmetric Key generated by Vereign App. Access and Refresh Tokens will be encrypted with 3rd Party App Server certificate.
    # Theory
    - https://tools.ietf.org/html/rfc8252 (This is best current practice proposed by Google for mobile base authentication)
    # Architecture
    ## Workflows
    - If user clicks on the Vereign App directly then Vereign App opens Vereign dashboard web app in Custom Chrome Tab/IOS View Controller (cookies and local storage are shared with native Browser)
    - If user uses the 3rd Party App workflow, then slightly modified IETF prosposed workflow is executed. Only Vereign App has Oauth2 secret key and it is transferred to the server using the standard IETF approach.
    ## Projects used
    - https://github.com/openid/AppAuth-Android - We are wrapping this library with Flutter Android wrapper
    - https://github.com/openid/AppAuth-iOS - We are wrapping this library with Flutter iOS wrapper
    ## Current Approach
    +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
    | User Device |
    | |
    | +--------------------------+ |
    | | | |
    | | 3rd Party App | |
    | | | |
    | +--------------------------+ |
    | | ^ |
    | | | |
    | | | |
    | | (1) | (8) |
    | | 3rd Party | Access |
    | | App Return | Token, |
    | | Link | Refresh |
    | | | Token |
    | | | And Vereign |
    | | | Server |
    | | | Url |
    | | | |
    | | | |
    | v | |
    | +--------------------------+ | (6) Authorization +---------------+
    | | | | Code | |
    | | Vereign Auth App |---------------------->| Token |
    | | |<----------------------| Endpoint |
    | +--------------------------+ | (7) Access Token, | |
    | | ^ | Refresh Token +---------------+
    | | | |
    | | | |
    | | (2) | (5) |
    | | Authorizat- | Authoriza- |
    | | ion Request | tion Code |
    | | | |
    | | | |
    | v | |
    | +---------------------------+ | (3) Authorization +---------------+
    | | | | Request | |
    | | Browser |--------------------->| Authorization |
    | | |<---------------------| Endpoint |
    | +---------------------------+ | (4) Authorization | |
    | | Code +---------------+
    +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
    ## Better Security Approach
    +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
    | User Device | (11) HTTPS Decrypt
    | | Request
    | +--------------------------+ | (1) HTTPS Auth +---------------+
    | | | | Request | |
    | | 3rd Party App |---------------------->| 3rd Party |----> Here 3rd Party App Server
    | | |<----------------------| App Server | Encrypts the 3rd Party App Return LInk
    | +--------------------------+ | (2) 3rd Party App | | with Vereign Server Certificate
    | | ^ | Return Link +---------------+ On (12) server decrypts data encrypted by
    | | | | Encrypted With Vereign Server and serves it back to 3rd
    | | | | Vereign Server Party App
    | | (3) | (10) | Certificate
    | | 3rd Party | Access | (12) Access,
    | | App Return | Token, | Refresh Tokens
    | | Link | Refresh | and Vereign
    | | | Token | Server Url
    | | | And Vereign | Decrypted
    | | | Server |
    | | | Url |
    | | | |
    | | | |
    | v | |
    | +--------------------------+ | (9) Authorization +---------------+
    | | | | Code | |----> Here Vereign Server encrypts
    | | Vereign Auth App |---------------------->| Token | Access and Refresh Tokens with
    | | |<----------------------| Endpoint | 3rd Party App Server Certificate
    | +--------------------------+ | (8) Access Token, | | ----------------------------------------
    | | ^ | Refresh Token +---------------+ Vereign AuthApp uses 3rd Party App
    | | | | Server certificate to encrypt Vereign
    | | | | Server Url
    | | (4) | (7) |
    | | Authorizat- | Authoriza- |
    | | ion Request | tion Code |
    | | | |
    | | | |
    | v | |
    | +---------------------------+ | (5) Authorization +---------------+
    | | | | Request | |----> Here Vereign Server decrypts
    | | Browser |--------------------->| Authorization | 3rd Party App Return Link
    | | |<---------------------| Endpoint | and encrypts it with the generated
    | +---------------------------+ | (6) Authorization | | Symmetric Key
    | | Code +---------------+
    +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
    # Setup Project
    ## Debug
    - Development `make run`
    - Production `make target=production run`
    ......
    0% or .
    You are about to add 0 people to the discussion. Proceed with caution.
    Finish editing this message first!
    Please register or to comment