请求实现从Site A到Site B的访问授权及Single Sign On方案咨询

Hey Alex, no worries about not being a pro dev/architect—your scenario is super clear, and we’ll walk through this in simple, actionable steps using OAuth 2.0 (a common, approachable SSO standard perfect for your tech stacks).

核心思路 #

We’re going to set up Site A as the OAuth 2.0 Authorization Server (it’s the source of truth for user logins/permissions) and Site B as the OAuth 2.0 Client (it trusts Site A to verify user identities). Here’s the high-level flow:

1. You’re logged into Site A (already authorized)
2. Click the link from Site A to Site B
3. Site B checks if you’re authenticated locally—if not, it sends you back to Site A to confirm your identity
4. Site A confirms you’re logged in, sends a secure "authorization code" back to Site B
5. Site B uses that code to fetch a "access token" from Site A
6. Site B validates the token, checks your permissions, and lets you access its pages

Step 1: Set up Site A (Java) as the Authorization Server #

Since Site A is a Java project, frameworks like Spring Security OAuth 2.0 (for Spring apps) or Apache Oltu work great. Here’s the key configuration you need:

• Register Site B as a "trusted client" in Site A’s auth server: assign a unique client_id and a secure client_secret (keep this secret locked down!)
• Build a login endpoint that verifies if the user is already logged into Site A
• Create an authorization endpoint that generates the authorization code for trusted clients
• Add a token endpoint that exchanges the authorization code for an access token
• Set up a user info endpoint that returns basic user details (like ID, role) when given a valid access token

Quick code snippet (Spring Boot example) #

@Configuration
@EnableAuthorizationServer
public class AuthServerConfig extends AuthorizationServerConfigurerAdapter {
    @Autowired
    private AuthenticationManager authenticationManager;

    @Override
    public void configure(ClientDetailsServiceConfigurer clients) throws Exception {
        clients.inMemory()
               .withClient("siteB-client") // Site B's unique client ID
               .secret("{noop}siteB-super-secret") // Use password encoding in production!
               .authorizedGrantTypes("authorization_code") // We're using the authorization code flow
               .scopes("read", "siteB-access") // Permissions Site B can request
               .redirectUris("http://www.siteB.com/callback"); // Site B's callback URL to receive the code
    }

    @Override
    public void configure(AuthorizationServerEndpointsConfigurer endpoints) throws Exception {
        endpoints.authenticationManager(authenticationManager);
    }
}

Step 2: Set up Site B (MEAN Stack) as the OAuth Client #

Site B has two parts: AngularJS frontend and Node.js backend. We’ll handle both:

Node.js Backend (Express) #

Use passport-oauth2 to manage the OAuth flow:

1. Install dependencies: npm install passport passport-oauth2 express-session
2. Configure Passport to connect to Site A’s auth server:

const passport = require('passport');
const OAuth2Strategy = require('passport-oauth2').Strategy;

passport.use(new OAuth2Strategy({
    authorizationURL: 'http://www.siteA.com/oauth/authorize', // Site A's authorization endpoint
    tokenURL: 'http://www.siteA.com/oauth/token', // Site A's token endpoint
    clientID: 'siteB-client', // Match the client ID registered in Site A
    clientSecret: 'siteB-super-secret', // Match the client secret
    callbackURL: 'http://www.siteB.com/callback' // Your backend's callback endpoint
},
function(accessToken, refreshToken, profile, done) {
    // Fetch user info from Site A using the access token
    fetch('http://www.siteA.com/api/userinfo', {
        headers: { 'Authorization': `Bearer ${accessToken}` }
    })
    .then(res => res.json())
    .then(user => {
        // Check if the user is authorized to access Site B
        if (user.hasSiteBAccess) {
            return done(null, user);
        } else {
            return done(new Error('User not authorized for Site B'), null);
        }
    })
    .catch(err => done(err));
}));

// Set up session management to keep users authenticated
app.use(session({ secret: 'siteB-session-secret-123', resave: false, saveUninitialized: false }));
app.use(passport.initialize());
app.use(passport.session());

// Serialize/deserialize user for session storage
passport.serializeUser((user, done) => done(null, user.id));
passport.deserializeUser((id, done) => {
    // You can store user data in Site B's DB or fetch from Site A each time
    done(null, { id });
});

// Callback endpoint to handle the authorization code
app.get('/callback', passport.authenticate('oauth2', { failureRedirect: '/unauthorized' }), (req, res) => {
    // Redirect to Site B's main authorized page
    res.redirect('/dashboard');
});

// Protect your Site B routes
app.get('/dashboard', (req, res) => {
    if (!req.isAuthenticated()) {
        // Redirect to Site A's auth flow if user isn't logged in
        res.redirect('/auth/siteA');
    } else {
        // Serve the authorized dashboard page
        res.sendFile('dashboard.html');
    }
});

// Route to start the OAuth flow
app.get('/auth/siteA', passport.authenticate('oauth2'));

AngularJS Frontend #

1. Add a link in Site A that points directly to Site B’s protected route (e.g., http://www.siteB.com/dashboard)
2. In Site B’s frontend, add an "Unauthorized" page for users who don’t have permission to access the site
3. The Node.js backend will automatically handle redirects to Site A’s auth flow if an unauthenticated user tries to access protected pages

Step 3: Test the Flow #

1. Log into Site A with an authorized user
2. Click the link to Site B’s /dashboard page—you’ll be briefly redirected to Site A (since you’re already logged in, this will feel seamless)
3. You’ll land on Site B’s dashboard without needing to log in again
4. If you try to access Site B directly without logging into Site A first, you’ll be sent to Site A’s login page

Key Tips for Non-Pro Devs #

• Secrets safety: Never hardcode client_secret or session secrets in your code—use environment variables instead
• HTTPS first: In production, always use HTTPS to prevent token interception
• Permission checks: Make sure Site A’s user info includes a clear flag/role indicating if the user can access Site B
• Simple error handling: Add basic error pages for cases like invalid tokens, unauthorized users, or network issues

内容的提问来源于stack exchange，提问作者Alex Sim