Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add abstraction for authentication strategy #2466

Closed
4 of 5 tasks
jannyHou opened this issue Feb 25, 2019 · 3 comments
Closed
4 of 5 tasks

Add abstraction for authentication strategy #2466

jannyHou opened this issue Feb 25, 2019 · 3 comments

Comments

@jannyHou
Copy link
Contributor

jannyHou commented Feb 25, 2019

Feature

Define an interface to describe the authentication strategy. It should contain

  • a function authenticate that verifies the request.
  • function authenticate should take in an option to perform the auth action accordingly.
  • document if people want to use services in the authentication strategy, they can inject the service in the strategy constructor

Acceptance Criteria

  • Verify the interface works by refactoring the Shopping Cart example to utilize it.
  • Verify the interface works by refactoring the Shopping Cart example to utilize it and strategies registered via extension points.

Parent story see #1035 (comment) (step 1b)

@bajtos
Copy link
Member

bajtos commented Mar 5, 2019

How is this story different from #2311 and #2312? Is it a pre-requisite that must be implemented first, before we can work on an extension point?

As I wrote in #2312 (comment), I think the authentication strategy abstraction should be defined around what LoopBack-specific strategies need and allow us to write an adapter to convert Passport strategies into LoopBack strategies.

What I am trying to say: The approach shown in the current version of @loopback/authentication, where we use Passport's Strategy interface as the API contract between LoopBack strategies and the authentication component, is something we should abandon in favor of a more flexible solution.

@jannyHou
Copy link
Contributor Author

@bajtos

How is this story different from #2311 and #2312? Is it a pre-requisite that must be implemented first, before we can work on an extension point?

This story simply creates the interface for auth strategy, the interface will be mostly the same as what is proposed in the design file

@samarpanB
Copy link
Contributor

@bajtos we have done oauth 2 integration as a separate component in our LB4 application very recently. We followed the guidelines shared here. I am not too sure what different aspect is getting implemented here or any of the authentication tasks. But if there is any way I can help/contribute, do let me know. I can share our implementation as well, if needed. That's not so robust but it was workable for us. We also did authorisation component but I would mention that in the appropriate issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants