mboost-dp1

IETF

Google Apps får OAuth til API-kald

- Via InfoWorld -

Google har åbnet for muligheden for at bruge OAuth til autentifikation over for seks Google Apps-API’er.

Det betyder, at en applikation ikke behøver sende brugernavn og password for at få adgang til et af API’erne. I stedet kan den sende et OAuth-token.

Foreløbig er OAuth understøttet i disse API’er:
[list]
[li]Provisioning API[/li]
[li]Email Migration API[/li]
[li]Admin Settings API[/li]
[li]Calendar Resource API[/li]
[li]Email Settings API[/li]
[li]Audit API[/li][/list]
Ankur Jain fra Google fremhæver i et blogindlæg, at metoden kan øge sikkerheden. Man kan således give et OAuth-token en udløbsdato, hvorefter det ikke længere kan bruges. Og man kan begrænse, hvilke API’er et token giver adgang til at kalde.

Google beskriver teknologien nærmere i OAuth API Reference.





Gå til bund
Gravatar #1 - Cloud02
29. sep. 2010 12:08
Det var da på tide at de fik fingeren ud og implementerede OAuth.
Manglen på det har i store træk undermineret sikkerhed, ved at folk vænner sig til at skrive username og password på semi-troværdige sider.
Gravatar #2 - dengulebaron
29. sep. 2010 12:22
Hvad er fidusen med OAuth?
Gravatar #3 - Scapegoat
29. sep. 2010 12:36
#2 Bare ret mig hvis jeg misforstår, men tror det er lidt ligesom noget digital signatur. Altså hvor du har adgang til nogle forskellige steder, uden at du skal indtaste oplysninger, men stadig hvor du har en del sikkerhed.
Gravatar #4 - Mulpacha
29. sep. 2010 12:45
OAuth bruges også af den fremtidige decentraliserede FaceBook-afløser Diaspora. (Video om Diaspora)
Gravatar #5 - redhead
29. sep. 2010 16:01
Men var Oauth ikke skarpt kritiseret netop fordi den udveksler en token som erstatning for login oplysninger ?
Gravatar #6 - Taxwars
30. sep. 2010 01:19
dengulebaron (2) skrev:
Hvad er fidusen med OAuth?


Du har en konto på WebsiteA, men login navn og password.

WebsiteB kan nogle sjove ting som kan virke sammen med WebsiteA.

Før var du nød til at give WebsiteB dit login navn og password og håbe på de ikke var ude på noget.

Med Oauth kan WebsiteB "stillet dig om" til WebsiteA som spørger om er iorden at lukke WebsiteB ind - hvis du siger ja uveksler de en kode, så WebsiteB kan komme ind på din konto på WebsiteA uden at kende dit password.

På WebsiteA kan du så logge ind med dit password og se hvilke sites du har givet lov til at komme ind med Oauth, og du kan trække tilladelsen tilbage igen hvis du ikke vil bruge de andre mere.

Et eksempel kunne være twitter - du har en twitter.com konto. I stedet for at bruge twitters eget website vil du heller bruge seesmic.com til at poste på twitter - ved hjælp af Oauth kan du posted beskeder på twitter uden at seesmic kender dit password.
Gravatar #7 - Torben B. Sørensen
30. sep. 2010 08:02
#5: Kritikken gik ikke på modellen med tokens, men på implementeringen af sikkerhed ved udveksling af tokens. De fleste er vist enige om, at det er langt bedre at bruge tokens end brugernavn/password til autentifikation. Brugerne slipper for at holde styr på en masse passwords, og mulighederne for misbrug kan begrænses ved at angive, hvad et token giver adgang til.

Den omtalte kritik siger, at der ikke er noget problem, når en applikation snakker med et Google API og bruger OAuth til autentifikation. Men den valgte sikkerhedsmodel, hvor man bruger SSL-kryptering, kan ikke bruges i en verden, hvor den samme token også skal bruges til Facebook og Twitter (hvis jeg har forstået det ret).
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login