Replace auth system

[verti-go]

AuthProvider plugin

AuthProvider

• preInterceptors
• postInterceptors

interception pipeline -- factor out -- move to generic higher mod?

interceptors become plugins -- register interceptors -- provide rules to apply interceptors.

interceptors that alter outgoing request - "pre" interceptors that alter incoming data - "post"

-- druid:http

http module: exposes two plugins 1.) PreprocessInterceptor 2.) PostprocessInterceptor

http -> (preprocess int) [...plugins] -> request http -> (postprocess int) [...plugins] -> response

module that wraps http requests and responses with change pipeline using plugins.

No reason to support anything but json tokens. If you aren't using json web tokens (jwt) you are a moron. I'm not going to write code to facilitate your stupidity. I might make the plugin generic enough to support that.

state stateless

login

• external
• internal

shared user attributes across vendors

• identity

Multiple vendors can share the same strategy - like oauth

auth strategy - plugin (auth strategy)

Auth strategies will be dependent on different libs.

Always should have the option to override strategy and provide own custom strategy.

[verti-go]

module authclient, plugin: authclient<t>{ constructor: <t>, preInterceptors: Array<callable<...>>, postInterceptors: Array<callable<...>> }

• provides auth (client || strategy)? plugin

module oidc, deps: authclient, plugin(authclient): oidcclient{}^authclient

• implements auth client

module cognito, deps: oidc

• uses oidc?

other:

• active auth clients become part of application context

[windbeneathyourwings]

Much of this has been resolved.

New module oidc has been created. Oidc implementation pieces inside auth have been removed and placed inside oidc instead. The auth module now provides only shared code between all implementations like the auth state / user model. The oidc module owns the feature that interacts with oidc-client through effects originating from auth. This architecture provides a nice, clean extensible starting point. The token intercpetor has also been moved inside oidc client because it seems most appropriate to live there for now.

The last part of this is to figure out how to deal with the cookies. The cookies are not oidc spec. The cookies are purely for cognito based logins. Therefore, I think it makes sense to consider a cognito module that will own an effect to add the cookies. Although the cookie data array still remains as part of the top level auth state because I think it makes sense there. Cookies are something other vendors could implement.