Erlaubt OAuth2 die Autorisierung mit Nicht-Passwort oder benutzerdefinierten Anmeldeinformationen?

Question

Ich verwende Spring Security OAuth2. Die Clientanwendung (die wir besitzen) erstellt eine "Kennwort" -Grantanfrage, die den Benutzernamen und das Passwort des Benutzers weitergibt. Genau wie der Entwurf spezifiziert.

Ich brauche diesen Mechanismus auch andere Arten von Berechtigungsnachweisen, wie Kartennummer, PIN, und sogar einen vorauthentifiziert, das Kennwort nicht erforderlich Zuschuss zu unterstützen.

Bitte beachten Sie, werden diese Anforderungen nur von einem privilegierten client_id erlaubt sein, eine, die nur von der Anwendung verwendet werden, werden wir besitzen.

Answer 1

Dave, vielen Dank für die schnelle Antwort. Ich fand tatsächlich die perfekte Lösung, eine, an der Sie teilgenommen haben. Es hat mit "Custom-Grant" -Token-Graner zu tun ... https://jira.spring.io/browse/SECOAUTH-347

Hatte ich meine ziemlich alte Version 1.0.0.M5 aktualisiert, die ich vielleicht gewusst hätte über diese.

Mein Ansatz war AbstractTokenGranter mit einer Klasse zu erweitern, die einen benutzerdefinierten Zuschuss Typen unterstützt (ich nenne es „Student“). Sobald eine Authentifizierungsanfrage hier angekommen ist, untersuche ich die Parameterliste genau wie ResourceOwnerPasswordTokenGranter, suche aber stattdessen nach meinem benutzerdefinierten Parameter "cardNumber". Ich übergebe dann meine eigene ID-basierte Version von UsernamePasswordAuthenticationToken an meinen AuthenticationProvider, der weiß, wie man Benutzer anhand der ID-Karte authentifiziert. Hier

ist der Brauch Token granter Klasse kam ich mit:

public class StudentCardTokenGranter extends AbstractTokenGranter { 
    private static final String   GRANT_TYPE = "studentCard"; 

    private final AuthenticationManager authenticationManager; 

    public StudentCardTokenGranter(AuthenticationManager authenticationManager, 
     AuthorizationServerTokenServices tokenServices, ClientDetailsService clientDetailsService) { 
    super(tokenServices, clientDetailsService, GRANT_TYPE); 
    this.authenticationManager = authenticationManager; 
    } 

    @Override 
    protected OAuth2Authentication getOAuth2Authentication(AuthorizationRequest clientToken) { 

    Map<String, String> parameters = clientToken.getAuthorizationParameters(); 
    String cardNumber = parameters.get("cardNumber"); 

    Authentication userAuth = new StudentCardAuthenticationToken(cardNumber); 
    try { 
     userAuth = authenticationManager.authenticate(userAuth); 
    } catch (BadCredentialsException e) { 
     // If the username/password are wrong the spec says we should send 400/bad grant 
     throw new InvalidGrantException(e.getMessage()); 
    } 
    if (userAuth == null || !userAuth.isAuthenticated()) { 
     throw new InvalidGrantException("Could not authenticate student: " + cardNumber); 
    } 

    return new OAuth2Authentication(clientToken, userAuth); 
    } 
} 

Und mein Autorisierungsserver config:

<!-- Issues tokens for both client and client/user authorization requests --> 
<oauth:authorization-server client-details-service-ref="clientDetails" token-services-ref="tokenServices"> 
    <oauth:refresh-token /> 
    <oauth:client-credentials /> 
    <oauth:password authentication-manager-ref="myUserManager" /> 
    <oauth:custom-grant token-granter-ref="studentCardGranter" /> 
</oauth:authorization-server> 
<bean id="studentCardGranter" class="com.api.security.StudentCardTokenGranter"> 
    <constructor-arg name="authenticationManager" ref="myUserManager" /> 
    <constructor-arg name="tokenServices" ref="tokenServices" /> 
    <constructor-arg name="clientDetailsService" ref="clientDetails" /> 
</bean> 

Answer 2

Die Spezifikation nicht explizit erlaubt die direkten, nicht-passwortbasierten Austausch von Benutzertoken zwischen einem Client und der Auth-Server direkt. Ich denke, es wäre ganz natürlich, die Passwortvergabe auf andere Formen der Authentifizierung zu erweitern. Es ist im Geiste der Spezifikation, wenn nicht vom Buchstaben, also, wenn Sie beide Seiten der Beziehung besitzen, gibt es nicht viel zu schiefgehen. Spring OAuth unterstützt nicht explizit alles, was die Passwortvergabe auf diese Weise erweitert, aber es ist nicht schwer zu tun (es geht nur um die Sicherheit des Endpunkts/token). Ein alternativer Ansatz, den ich gesehen habe, besteht darin, beim Passwortvergabeprotokoll zu bleiben, aber das "Passwort" zu einem einmaligen Token zu machen, das der Client nur erhalten kann, wenn er weiß, dass sich der Benutzer auf eine dieser alternativen Arten authentifiziert hat.