Hacker News Reader

Comment by Lx1oG-AWb6h_ZG0 | Hacker News Reader

Maybe I’m missing something, but what is the advantage of maintaining a separate oauth provider (sso-auth)? Since they apparently need to support just google creds, why not let sso-proxy talk to google directly? Why do they need to maintain a separate token infrastructure?

The other (related) question is how the token refresh works - is it tied to the underlying refresh token generated by google, or is it something completely independent?

View on HN

sso-auth allows you to authenticate against Google once, and then any other requests that come to it can be redirect back to the calling application without first hitting Google.

If you registered each new app directly with Google, every time the user visited a new app, they would be redirect to Google to provide permission to the app to log them in, and then be redirected back.

This is described in: https://tech.buzzfeed.com/unleashing-the-a6a1a5da39d6

> Now, their employees can securely access Ghost Land at ghost-land.sso.pacworld.com

That’s the part I’m confused about. They force all sites that need SSO to be under the same subdomain. If they can share the same session cookie, why does each microservice need to redirect at all? Can’t they all use the same oauth app underneath?

One possible reason is they might want each microservice to be a separate security domain. So that if one microservice is compromised, attackers cannot use credentials stolen from that microservice to control other microservices.

There is no requirement for all of them to be under the same domain. It's not made clear in the article, but the documentation shows how you can run all of them under different domains too.

I think it's well explained in the article.

Reply on news.ycombinator.com