single signon systeem in combinatie met oauth?

[xilent_xage]

Hoi,

Ik zit met het volgende probleem:

Website X wordt beheerd door een externe partij. Zij willen producten uit een webshop Y die ik beheer kunnen aanbieden met korting aan hun leden. Die leden zijn ingelogd op de externe server X, en moeten middels een link op de webshop Y terecht komen. Daar moeten we dus controleren of de gebruiker wel is ingelogd op de externe server X, en vervolgens de producten tonen.

Opzich is het dus allemaal niet top-secret, dus we hoeven ook geen state-of-the-art beveiliging.Omdat de gebruikers altijd via de externe server komen (en dus nooit rechtstreeks op onze shop), stelde ik de volgende (houtje-touwtje-) oplossing voor:

1. De link naar onze website op de externe site X bevat een GET-variabele met een random string, iets als: www.webshopY.nl/index.php?token=1csdr
2. Zodra de request bij ons (Y) binnenkomt doen we via https een request naar de externe server X met daarin het IP-adres van de bezoeker en de token. Dit kan via GET of POST.
3. De externe server X geeft de userdata terug indien de combinatie van token & ip ingelogd is, en 0 indien de combinatie dat niet is. De externe server X werkt met IP-whitelisting om alleen requests van onze server Y te accepteren. Eventueel kun je tokens nog na x minuten laten expiren.

De externe partij kwam met een tegenvoorstel, waarbij we dit scenario combineren met oAuth. Nou heb ik daar niet heel veel ervaring mee, heb vroeger wel een aantal OpenID inlogsystemen gebouwd. In mijn herinnering (en ook voor zover ik nu bij elkaar heb gelezen) gaat oAuth eigenlijk uit van een ander scenario, en wordt het ook vooral gebruikt voor een ander soort toepassing: Het inloggen via een andere server en eventueel het beheren van hulpbronnen. Ik heb dus het idee dat:

• oAuth niet bedoeld is voor dit soort situaties
• oAuth overkill is voor dit vraagstuk
• oAuth in combinatie met bovenstaand voorstel dubbelop is
• Mijn voorstel oneindig veel simpeler is, en in dit geval veilig genoeg is.

Mijn vragen zijn dan:

1. Kloppen mijn stellingen? Zonee waar gaat het mis?
2. Indien oAuth toch the way to go is: heeft iemand een (linkje naar-) een voorbeeld van een implementie in een soortgelijk geval? Elk voorbeeld wat ik kan vinden gaat uit van een inlogsysteem op de webshop die voor toegang tot hulpbronnen op de externe server de login via de externe site laat lopen, en dat is net even iets anders dan wat ik wil?
3. Ons scenario lijkt me zeer vaak voorkomend en gebruikelijk. Zijn er ander etechnieken / standaarden die hiervoor bedoeld zijn die ik over het hoofd zie?

Alvast dank, en excuus voor het lange verhaal

[HuHu]

Het doorgeven van een token is zeer gebruikelijk. Ik zou in stap 2 nog wel een extra token toevoegen (de secret), die alleen bekend is bij X en Y en niet bij de gebruiker of derden.

Op het moment dat de gebruiker van website X naar een andere website gaat (malafide website Z) en de token staat in de referer-header, dan kan Z niet stiekem ook de gegevens opvragen. Stap 3 kan dan eventueel vervallen, maar erin houden kan geen kwaad.

Stap 2 wordt dan een HTTPS request met sha(token+secret). De secret gaat dan nooit openbaar over de verbinding.

[xilent_xage]

mooi. en dan is oAuth dus overbodig begrijp ik?

[creator1988]

Als ik nou op een mobiele connectie zit dan gaat je login verificatie niet zomaar werken, want mijn IP kan om de zoveel tijd veranderen. Ook moet de gebruiker recent zijn ingelogd op A ondanks dat je login token wel een jaar geldig kan zijn. IP based daarom niet echt handig.

Duidelijker volgens mij:

1. Gebruiker komt op website B, je doet een redirect naar website A
2. Website A encode data over de user, en signt met private key
3. Website B verifieert de key, decode en weet of de user ingelogd is

[HuHu]

xilent_xage schreef op vrijdag 25 januari 2013 @ 19:34:
mooi. en dan is oAuth dus overbodig begrijp ik?

Jep. Het is ook alleen maar lastig, want de gebruiker moet opnieuw inloggen om de website te autoriseren. Voor de gebruikers ervaring is het achter de schermen uitwisselen van tokens veel fijner.

Een veel gebruikte variant hierop is het insluiten van externe websites (uiteraard met toestemming) die een deel van je website faciliteren. Zo zijn er allerlei webwinkels die specifieke producten verkopen die ze zelf niet hebben, maar in overleg sluiten ze dan een iframe met de externe website in en geven via een token de klant-informatie door. De gebruiker merkt daar niets van, want hij lijkt nog steeds op dezelfde website te zitten.

[dcm360]

Of de gebruiker krijgt een niet goed functionerend iframe voor zn neus. Veel webbrowsers doen moeilijk als je scripts en/of cookies gebruikt in een iframe, om het niet te hebben over de problemen die mixen van http en diverse gradaties https met zich mee kan brengen. Tot op zekere hoogte valt daar best omheen te programmeren, maar je moet er rekening mee houden dat je geen invloed hebt op hoe strikt een webbrowser van een klant ingesteld staat.

[HuHu]

Als je een P3P header meestuurt vanuit het iframe, dan heb je geen problemen. Zeker niet als beide sites gewoon http gebruiken en geen https.