Authentication Systems

[the-maldridge]

@scauthen I opened this issue to discuss how authentication will work.

My opinion is that we should use JWT's which can be used as bearer tokens as well as queried for what capabilities a user may have. They will have a lifetime, but we can set this at something like an hour to make the renewal problem moot.

I don't think we should start with social login (oauth/gauth) as an option as that dramatically increases complexity, and until we can semi-permanently nail down the server name this operates under, it makes it very difficult to run that.

Its also worth pointing out that we're kind of inverting some flows that many BEST users are currently familiar with. Most notably we're transitioning here from logging in "as the hub" to logging in as a user who may manage a hub.

[scauthen]

Does this mean when a hub director creates their account in this system, someone on the admin side will have to recognize them as a hub director assign them to a hub? This would mean that directors (or anyone currently using the dashboard) would have one login (the Google authentication) to access the Dashboard and a second login to access the Registry system. Having two different accounts may be challenging for some people.

[the-maldridge]

Our existing google authentication really isn't serviceable, and I'll be surprised if it works through the end of the year. We can eventually support login via google accounts, but all that is is recognizing a secondary login flow (oauth2) and can be done after the fact. I think its a reasonable request to have hub directors hold a second account for a period of time while we get the system setup.

You are correct in that for existing hub directors we'll need to backfill the data, then manually set them as administrators of their hubs.

@gdyoung93 can explain more, but I believe the long term goal is to fold most of the functionality of the dashboard into a replacement system that is more maintainable. This could be viewed as phase 1 which moves hub management out of the dashboard and provides the features we want that simply can't be built into the current BRI platform.

[scauthen]

Ok. That makes sense. I was not aware the end goal was to replace the entire dashboard. That is something good to keep in mind (for myself) as we move forward. Just as a very high level roadmap, it might be nice to have a document that defines (in short terms) all the functionality that is to be developed. Keeping in mind it will change as we progress forward, it would be helpful as I start to layout the frontend file structure.

[the-maldridge]

Such documentation should be in docs/design feel free to add your own docs there as desired.

[gdyoung93]

Yes, that is long-term plan. I'm not sure what you are referring to about Google Auth going away? I think it is already oauth2. But, regardless, it will have to be updated if it changes. I haven't gotten any notice that it will be changing.

2nd login is OK temporarily but not long-term.

Greg

On Wed, Jan 23, 2019 at 3:09 PM Michael Aldridge notifications@github.com wrote:

Our existing google authentication really isn't serviceable, and I'll be surprised if it works through the end of the year. We can eventually support login via google accounts, but all that is is recognizing a secondary login flow (oauth2) and can be done after the fact. I think its a reasonable request to have hub directors hold a second account for a period of time while we get the system setup.

You are correct in that for existing hub directors we'll need to backfill the data, then manually set them as administrators of their hubs.

@gdyoung93 https://github.com/gdyoung93 can explain more, but I believe the long term goal is to fold most of the functionality of the dashboard into a replacement system that is more maintainable.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/BESTRobotics/registry/issues/4#issuecomment-456966939, or mute the thread https://github.com/notifications/unsubscribe-auth/Aswa0Kr3xWyuzPUBhkQklGZkURlnA2zQks5vGM-HgaJpZM4aN5o5 .

[the-maldridge]

I'm referring to the kind of embedded click-bounce-auth button currently in use which already has some trouble validating the session. Bouncing through that many domains is not something that oauth was designed to do. I'm also fairly sure that we're on oauth, not oauth2.

I foresee that we'd need to sustain the 2nd login for ~6 months in the worst case.

[gdyoung93]

Yeah, that's a Google thing. It used to be much simpler. This latest incarnation does have trouble and I'd love to fix it.

greg

On Wed, Jan 23, 2019 at 3:48 PM Michael Aldridge notifications@github.com wrote:

I'm referring to the kind of embedded click-bounce-auth button currently in use which already has some trouble validating the session. Bouncing through that many domains is not something that oauth was designed to do. I'm also fairly sure that we're on oauth, not oauth2.

I foresee that we'd need to sustain the 2nd login for ~6 months in the worst case.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/BESTRobotics/registry/issues/4#issuecomment-456979558, or mute the thread https://github.com/notifications/unsubscribe-auth/Aswa0Mmidls_WVERdWNOuDuH2i_a13Hbks5vGNi4gaJpZM4aN5o5 .

[the-maldridge]

I'm looking into this for user authentication and registration: https://github.com/qor/auth

It seems to do everything under the sun and so would work for our purposes, but the maintenance history isn't exactly what I'd like. I think we may start out with users that have no authentication, then go from there so as to not stall out the project.

EDIT: This seems significantly more complete and better maintained, but I still think we should dodge the external auth complexity initially and just use fully local accounts: https://github.com/markbates/goth

[the-maldridge]

Username/password working, goth integration remains to be done.