Saml vs. Oauth

Saml og Oauth er tekniske standarder for å autorisere brukere. Disse standardene brukes av webapplikasjonsutviklere, sikkerhetsfagfolk og systemadministratorer som ønsker å forbedre sin identitetsstyringstjeneste og forbedre metoder som klienter kan få tilgang til ressurser med et sett med legitimasjon. I tilfeller der tilgang til en applikasjon fra en portal er nødvendig, er det behov for en sentralisert identitetskilde eller enterprise enkeltskilt på. I slike tilfeller er SAML å foretrekke. I tilfeller der midlertidig tilgang til ressurser som kontoer eller filer er nødvendig, regnes Oauth som det bedre valget. I tilfeller av mobilbruk brukes OAuth stort sett. Både SAML (sikkerhetspåstand og markeringsspråk) og OAuth (åpen autorisasjon) brukes til web-enkelt signering på, og gir alternativet for enkelt pålogging for flere webapplikasjoner.

Saml

Saml brukes til å la webapplikasjonenes SSO -leverandører overføre og flytte legitimasjon mellom identitetsleverandøren (IDP), som har legitimasjonen, og tjenesteleverandøren (SP), som er ressursen som trenger disse legitimasjonene. Saml er et standard autorisasjons- og autentiseringsprotokollspråk som for det meste brukes til å utføre føderasjon og identitetsstyring, sammen med enkelttegn på ledelse. I Saml, XML -metadatadokumenter brukes som et symbol på innsending av klientens identitet. Godkjennings- og autorisasjonsprosessen til Saml er som følgende:

1. Brukeren ber om å logge seg på tjenesten via nettleseren.
2. Tjenesten informerer nettleseren om at den er autentiserende for en spesifikk identitetsleverandør (IDP) registrert med tjenesten.
3. Nettleseren videresender godkjenningsforespørselen til de registrerte identitetsleverandørene for innlogging og autentisering.
4. Ved vellykket legitimasjon/autentiseringssjekk genererer IDP et XML-basert påstandsdokument som verifiserer brukerens identitet og videresender dette til nettleseren.
5. Nettleseren videresender påstanden til tjenesteleverandøren.
6. Tjenesteleverandøren (SP) godtar påstanden for oppføring og gir brukeren tilgang til tjenesten ved å logge dem inn.

La oss nå se på et ekte eksempel. Anta at en bruker klikker på Logg Inn Alternativ på bildedelingstjenesten på nettstedet ABC.com. For å autentisere brukeren, fremsettes en kryptert SAML -godkjenningsforespørsel av ABC.com. Forespørselen vil bli sendt fra nettstedet direkte til autorisasjonsserveren (IDP). Her vil tjenesteleverandøren omdirigere brukeren til IDP for autorisasjon. IDP vil bekrefte den mottatte SAML -godkjenningsforespørselen, og hvis forespørselen viser seg gyldig, vil den presentere brukeren med et påloggingsskjema for å oppgi legitimasjonen. Etter at brukeren har lagt inn legitimasjonen, vil IDP generere en SAML -påstand eller SAML -token som inneholder brukerens data og identitet og vil sende den til tjenesteleverandøren. Tjenesteleverandøren (SP) verifiserer SAML -påstanden og trekker ut dataene og identiteten til brukeren, tildeler de riktige tillatelsene til brukeren og logger brukeren inn i tjenesten.

Utviklere av webapplikasjoner kan bruke SAML -plugins for å sikre at appen og ressursen begge følger det nødvendige enkeltskiltet på praksis. Dette vil gi en bedre brukeropplevelsesopplevelse og mer effektiv sikkerhetspraksis som utnytter en felles identitetsstrategi. Med Saml på plass er det bare brukere med riktig identitet og påstandstoken som får tilgang til ressursen.

Oauth

Oauth brukes når det er behov for å gi autorisasjon fra en tjeneste til en annen tjeneste uten å dele den faktiske legitimasjonen, som passordet og brukernavnet. Ved hjelp av Oauth, Brukere kan logge på en enkelt tjeneste, få tilgang til ressursene til andre tjenester og utføre handlinger på tjenesten. OAuth er den beste metoden som brukes til å gi autorisasjon fra et enkelt tegn på plattform til en annen tjeneste eller plattform, eller mellom to webapplikasjoner. De Oauth Arbeidsflyt er som følger:

1. Brukeren klikker på påloggingsknappen til en ressursdelingstjeneste.
2. Ressursserveren viser brukeren et autorisasjonsstipend og omdirigerer brukeren til autorisasjonsserveren.
3. Brukeren ber om et tilgangstoken fra autorisasjonsserveren ved å bruke autorisasjonsstipendkoden.
4. Hvis koden er gyldig etter å ha logget på autorisasjonsserveren, vil brukeren få et tilgangstoken som kan brukes til å hente eller få tilgang til en beskyttet ressurs fra ressursserveren.
5. Når du mottar en forespørsel om en beskyttet ressurs med et tilgangstilskudd, blir gyldigheten av Access Token sjekket av ressursserveren ved hjelp av autorisasjonsserveren.
6. Hvis symbolet er gyldig og passerer alle sjekkene, er den beskyttede ressursen gitt av ressursserveren.

En vanlig bruk av OAuth lar en webapplikasjon få tilgang til en plattform for sosiale medier eller annen online konto. Google -brukerkontoer kan brukes med mange forbrukerapplikasjoner av flere forskjellige grunner, for eksempel blogging, online spill, logge på med sosiale mediekontoer og lese artikler på nyhetsnettsteder. I disse tilfellene jobber Oauth i bakgrunnen, slik at disse eksterne enhetene kan kobles sammen og kan få tilgang til nødvendige data.

OAuth er en nødvendighet, da det må være en måte å sende autorisasjonsinformasjon mellom forskjellige applikasjoner uten å dele eller utsette brukeropplysning. OAuth brukes også i bedrifter. Anta for eksempel at en bruker må få tilgang til et selskaps enkeltskilt på systemet med brukernavn og passord. SSO gir den tilgang til alle nødvendige ressurser ved å sende Oauth -autorisasjons -symboler til disse appene eller ressursene.

Konklusjon

OAuth og SAML er begge veldig viktige fra en webapplikasjonsutvikler eller systemadministrators synspunkt, mens begge er veldig forskjellige verktøy med forskjellige funksjoner. OAuth er protokollen for tilgangsgodkjenning, mens SAML er et sekundært sted som analyserer innspillet og gir autorisasjon til brukeren.