Third Party Login RFC

[djmitche]

@helfi92 let me know what you think about the updates here. It's a lot of text, but hopefully there are libraries to implement OAuth2 authentication servers. The two big bits that differ from "regular" OAuth2 are

• scope query parameter contains TC scopes
• expires query parameter

[djmitche]

@ajvb I'd like your input here, too? Also @garbas and @armenzg.

[djmitche]

I'd request that modifications to the OAuth2 flow be documented in one central location. This would assist with reviewing diversion's from the standard flow and assist with any future (security) audits.

Sounds good -- I'll add something similar to my comment yesterday.

[armenzg]

This sounds good to me.

Maybe I completely missed but why is this change required?

[djmitche]

Maybe I completely missed but why is this change required?

The document talks about the disadvantages of the "old way", but the key reason that this is required now is that we are not migrating the code that supports the "old way" to the new, cloudops-managed deployment.

[djmitche]

There's been some justified concern over the tight timeline for existing third-parties. I think we can work around that by leaving the existing login mechanism up and generating credentials even while the new system is running. With this approach, third parties may need to change rootUrls in their configuration, but should be able to avoid having to turn on a completely new implementation during the September TCW.

I've added a section to the proposal about this.

I'm on PTO for the rest of the week, and I don't think anyone is actively pondering a response to this right now, so I'm going to move it to Final Comment until next Monday. If things have come up when I get back, I'll revise and try again.

[djmitche]

No comments here or by email, so we'll call this decided!