OAuth gebruiken om de toegang tot zakelijke webservices voor mobiele webpagina's en native apps te beperken

Ik overweeg een ontwerp dat ik er niet zeker van ben of OAuth een goede fit gaat worden, maar dit is de basiskwestie.

Ik heb corporate webservices die verschillende niveaus van beveiliging vereisen.

  1. Controleer beoordelingen voor gebruiker - gebruikersnaam/wachtwoord
  2. Cijfers wijzigen voor gebruiker - gebruikersnaam/wachtwoord/RSA-tokennummer

Dus als een toepassing wil doen (1), zal het om de inloggegevens vragen, maar, ik zou graag zien dat de OAuth-server te horen krijgt welke dienst de gebruiker probeert te bereiken, en de juiste velden getoond worden, zoals dit is de eerste login.

Nu, de tweede keer, heeft de applicatie (browser of app) een token, maar dat token is niet voldoende, maar de applicatie zou dit niet moeten weten, omdat de beveiligingsvereisten kunnen veranderen, op basis van wat de beveiligingsmensen beslissen is gepast.

Dus wanneer het token gepresenteerd wordt om bij (2) te komen, bepaalt het dat het niet voldoende is, en dus wordt er een fout teruggestuurd, zodat de applicatie kan gaan en proberen een nieuw token te krijgen.

Ik heb dit nog niet geïmplementeerd, maar als basisontwerp ben ik er niet zeker van of OAuth goed past bij wat ik wil doen of als ik beter af zou zijn om mijn eigen authenticatiesysteem te schrijven.

Initieel zal de client voor de webservices mobiele web-apps zijn, maar ik wil het flexibel genoeg maken zodat we bij het schrijven van een native telefoon-app hetzelfde systeem kunnen gebruiken. Dus als de applicatie de beveiliging moet weten waar ik problemen mee heb, en telkens de referenties door te geven aan de webservice ben ik niet tevreden, dus zou ik liever een versleuteld token hebben dat kan worden gebruikt, en als je aan de vereisten voldoet voor (2) dan kunt u in (1) komen met dezelfde token.

Dus, zou OAuth hiervoor geschikt zijn?

OAuth heeft wel authenticatie-aspecten, zo lijkt het erop ( https://developers.google.com/ accounts/docs/OAuth2InstalledApp ).

UPDATE: - It appears that Open Connect (http://openid.net/connect/) may be better than OAuth for this, but I am just learning about Open Connect now.

 2
toegevoegd bewerkt
Bekeken: 2
de bron
ja ru es pt de ar
@Kos - Ik denk dat mijn probleem is dat ik het authenticatiedeel wil hebben voor het geval het autorisatiegedeelte niet aan de vereisten voldoet. Dus je hebt geen autorisatie voor (2), maar je deed dit voor (1), dus je moet eerst worden omgeleid om je te laten authenticeren voor (2). Ik ben geneigd om alleen mijn eigen systeem te bouwen, maar wil zoveel mogelijk gebruikmaken van geaccepteerde standaarden (of concepten).
toegevoegd de auteur James Black, de bron
Houd er rekening mee dat OAuth alleen autorisatie uitvoert en niet bezig is met authenticatie.
toegevoegd de auteur Kos, de bron

1 antwoord

Er zijn twee voordelen van het gebruik van oAuth naar mijn mening ...

  1. Gebruikers hoeven geen nieuwe gebruikersnaam/wachtwoord voor uw service te maken.
  2. U hoeft geen wachtwoord op te slaan of een SSL-certificaat te hebben om in te loggen (misschien heeft u SSL nodig voor andere dingen, niet zeker).

U zegt dat u twee diensten hebt. U wilt niet dat gebruikers zich bij beide moeten aanmelden, dus ik stel voor om een ​​gevel te maken (webservice) waar een gebruiker inlogt (met oAuth), omdat u een enkele callback-URL moet configureren. Vanuit die gevelservice kunt u bepaalde oproepen autoriseren en deze oproepen doorsturen naar de andere services.

Ik weet niet zeker wat de gebruiker Kos betekent, maar oAuth is voor verificatie en niet voor autorisatie in uw app (is mijn overtuiging ). U moet een oAuth-gebruiker toewijzen met een interne representatie van die gebruiker samen met toegangsrechten. Dit betekent nog steeds dat u een gebruiker ergens op uw kant moet opslaan. Het enige is dat u geen wachtwoord hoeft op te slaan en dat u geen aangepaste inlogpagina hoeft te ontwikkelen.

Dus in het kort kan oAuth u alleen vertellen dat een bepaalde gebruiker bekend is en is geverifieerd. De rest is aan jou. Het implementeren van oAuth is niet zo moeilijk, maar ook niet triviaal. Dus dit brengt ons terug naar de twee voordelen die ik eerder heb genoemd en je moet beslissen of en waarom je deze route wilt nemen.

1
toegevoegd
de bron