Skip to content

Third Party Integration - HTTP API, OAuth2 Provider API, Plugin API, Library vs Framework, Smart Tokens #166

@joshuakarp

Description

@joshuakarp

Created by @CMCDragonkai

Once we reintroduce OAuth2 into Polykey, because our OAuth2 requirements are pretty simple, it would be beneficial to implement it from scratch to reduce dependency requirements.

We have already implemented an Oauth2 client side from scratch in MR 141.

This would mean these dependencies we can get rid of:

    "oauth2orize": "^1.11.0",
    "passport-oauth2-client-password": "^0.1.2",
    "@types/oauth2orize": "^1.8.8",
    "@types/passport-oauth2-client-password": "^0.1.2",

Actually @CMCDragonkai is in favour of getting rid of password related libraries entirely so that we can be much lighterweight.

Like all of these:

    "passport": "^0.4.1",
    "passport-http": "^0.3.0",
    "passport-http-bearer": "^1.0.1",
    "@types/passport-http": "^0.3.8",
    "@types/passport-http-bearer": "^1.0.36",

In our usage of OAuth2 server-side, we would expect only a 2-legged flow. For example a "client-credentials-flow": https://docs.microsoft.com/en-us/linkedin/shared/authentication/client-credentials-flow

@CMCDragonkai : A client credentials flow is alot easier. And we should expect to just keep track of tokens, which we can use our vault system to store again.

Metadata

Metadata

Assignees

No one assigned

    Labels

    designRequires designr&d:polykey:core activity 1Secret Vault Sharing and Secret History ManagementresearchRequires research

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions