search

RecursiveThinking / recursive_thinking_website

Recursive Thinking Website
6 stars 2 forks source link

Investigate Cognito / Slack for Auth #24

Open amnevins opened 6 years ago

amnevins commented 6 years ago

Investigate Cognito / Slack for Auth. See if we can get a user pool with 3rd party slack integration, and a federated pool to let each authed user call AWS resources (invoke API's).

MynockSpit commented 6 years ago

Documentation on Slack Auth: https://api.slack.com/docs/sign-in-with-slack#authorization I made an app to test with way back when: https://api.slack.com/apps/A5D84TELQ

amnevins commented 6 years ago

So check out Auth.js, we now have all the helper methods to auth users. Users will sign in/sign up and be authed with our Cognito Identity Pool. Then we will use that credential to auth them with our federated pool. This gives them the ability to then make calls to the allocated AWS resources. Still havn't figured how we'll do slack yet but looks like cognito has expanded there third party auth.

MynockSpit commented 6 years ago

Cool! Looks good!

Not clear on the federating. Why are users accessing as resources? Are you thinking we'll hit Dynamo / S3 / other directly? I thought Lambda functions would make those calls.

amnevins commented 6 years ago

The users will have to have permission to invoke the lambdas. Otherwise we have a real admin user credential for backend... but thats scary ;)

MynockSpit commented 6 years ago

Huh? So the users are invoking the lambdas directly? Are you thinking we'll skip api gateway?

amnevins commented 6 years ago

I havnt thought that far ahead lol. Just getting cognito up, from there we can figure out how to cognito third party so they can sign in with slack credentials (and we can make an alternate method for that saves all the slack profile info, maybe this becomes the default and only way to sign up). The API -> Lambda -> DynamoDB and S3 stuff we'll have to figure out how all that's gonna work. I'm imaging it will all go through API Gateway with a Cognito Authorizer, we may not even need the federated stuff. I think we need the federated pool at least to the extent it lets our users modify cognito resources, I'm not sure if API Gateway does cognito federated or user pool auth... you'd know better than I :)

amnevins commented 6 years ago

So currently we have Sign In/Sign Up implemented via cognito as of issue #29 ! This is mostly to break ground on getting the code base to the point where we can save/edit user information and let the UI catch up to calling 'real' api's to return and edit the info. Working in Slack from there should just be a degree of separation, and the groundwork of all the components reaching out and editing real data will make it a Slack implementation only issue. This also keeps us from blocking the UI development while we work on getting Slack!

MynockSpit commented 6 years ago

Thinking this'll be the flow:

Login / Create User Flow

  1. User clicks "Sign in with Slack"
  2. Redirect to Slack's auth servers
  3. User "Okay's" RT's use of their creds
  4. Redirect back to RT with temporary code
  5. RT sends a request to Lambda to authenticate w/ temporary code
  6. Lambda uses temporary code to exchange for long-lived Slack Access Token
  7. [new user] Lambda creates Account in Cognito User Pool on behalf of the user using the AT as the password
  8. Lambda signs in as that user, gets Cognito Access Token
  9. Returns that to RT

Reset password flow If a user disallows RT's access to Slack, their user access token will be revoked and they won't be able to follow that flow. I propose that we automatically push this user down the Reset Password flow.

  1. User attempts to sign in with Slack (Steps 1 - 5 as above).
  2. Login fails.
  3. Initiate password reset.
  4. Password reset redirects to a lambda function, which then resets the password to the current Access Token.
  5. Continue at step 8 as above.

Not sure how easy it is to modify the password reset email/text sent. If it's easy, this'll be pretty simple. If not, it'll be a bit harder. I'd like to remove all user input here, but I don't see an easy way.

Thoughts?

MynockSpit commented 6 years ago

Blocked on 7 of the login flow. Amplify on Node has some bugs.

clsource commented 5 years ago

I believe this can be configured in Cognito using OIDC IDP https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-oidc-idp.html#cognito-user-pools-oidc-idp-step-1

MynockSpit commented 5 years ago

Last I check (a year ago?) Slack doesn't support OIDC. Maybe they do now.

clsource commented 5 years ago

It seems that they lack OIDC support. Some ideas:

1 - With the Slack Login Button. On success page. Create an account in Cognito (Using Lambda) with the same email but a random temporary password. So users do not need to signup, and can login with the same credentials (but need to remember a password).

2 - Create an OIDC Compatible Wrapper around Slack. Using services like https://www.keycloak.org/ or another Open Id Connect server that uses Slack Apis for the oAuth2 process and implements the missing standard methods.

danparker276 commented 4 years ago

It seems that they lack OIDC support. Some ideas:

1 - With the Slack Login Button. On success page. Create an account in Cognito (Using Lambda) with the same email but a random temporary password. So users do not need to signup, and can login with the same credentials (but need to remember a password).

2 - Create an OIDC Compatible Wrapper around Slack. Using services like https://www.keycloak.org/ or another Open Id Connect server that uses Slack Apis for the oAuth2 process and implements the missing standard methods.

Any update on this, or is this still the best way to do it?

jerriclynsjohn commented 3 years ago

Looks like there is an oidc compatible shim for slack that can be used with AWS Cognito. https://github.com/raulmt/slack-cognito-openid-wrapper

I'm still trying to get this working. Let me know if you got this working