Scribd Logo
Upload

Welcome to Scribd!

  • 96 views

    Saml Vs Oauth2 Terminology

    Uploaded by

    Rajesh
    SAML and OAuth2 are similar authentication protocols that both involve a service provider (resource server), client, and identity provider (authorization server). SAML involves the identity provider authenticating the user and generating a SAML token that is passed to the service provider. OAuth2 similarly involves the authorization server authenticating the user, but instead of a token it issues an authorization code and access token to the client, which can then request resources from the service provider on behalf of the user. Both protocols allow a user to authenticate with an identity provider and grant a service provider access without sharing their credentials.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd

    Saml Vs Oauth2 Terminology

    Uploaded by

    Rajesh
    96 views3 pages
    SAML and OAuth2 are similar authentication protocols that both involve a service provider (resource server), client, and identity provider (authorization server). SAML involves the identity provider authenticating the user and generating a SAML token that is passed to the service provider. OAuth2 similarly involves the authorization server authenticating the user, but instead of a token it issues an authorization code and access token to the client, which can then request resources from the service provider on behalf of the user. Both protocols allow a user to authenticate with an identity provider and grant a service provider access without sharing their credentials.

    Original Description:

    saml oath

    Original Title

    saml oath

    Copyright

    © © All Rights Reserved

    Available Formats

    DOCX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    SAML and OAuth2 are similar authentication protocols that both involve a service provider (resource server), client, and identity provider (authorization server). SAML involves the identity provider authenticating the user and generating a SAML token that is passed to the service provider. OAuth2 similarly involves the authorization server authenticating the user, but instead of a token it issues an authorization code and access token to the client, which can then request resources from the service provider on behalf of the user. Both protocols allow a user to authenticate with an identity provider and grant a service provider access without sharing their credentials.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    96 views3 pages

    Saml Vs Oauth2 Terminology

    Uploaded by

    Rajesh
    SAML and OAuth2 are similar authentication protocols that both involve a service provider (resource server), client, and identity provider (authorization server). SAML involves the identity provider authenticating the user and generating a SAML token that is passed to the service provider. OAuth2 similarly involves the authorization server authenticating the user, but instead of a token it issues an authorization code and access token to the client, which can then request resources from the service provider on behalf of the user. Both protocols allow a user to authenticate with an identity provider and grant a service provider access without sharing their credentials.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    of 3
    At a glance
    Powered by AI
    SAML and OAuth2 are both protocols for authentication and authorization but have some key differences. SAML focuses on authentication while OAuth2 focuses on authorization.

    SAML focuses on authentication between an identity provider and service provider, while OAuth2 focuses on authorization of a client application to access resources on a user's behalf from a resource server.

    The typical SAML flow involves a service provider redirecting a user's browser to an identity provider for authentication. If authentication is successful, the identity provider generates and returns a SAML token to the service provider containing user identity information.

    SAML vs OAuth2 terminology

    SAML and OAuth2 use similar terms for similar concepts. For comparison the formal SAML term is listed
    with the OAuth2 equivalent in parentheses.
     Service Provider (Resource Server) – this is the web-server you are trying to access information on.
     Client – this is how the user is interacting with the Resource Server, like a web app being served through a
    web browser.
     Identity Provider (Authorization Server) – this is the server that owns the user identities and credentials.
    It’s who the user actually authenticates with.
    The most common SAML flow is shown below:

    Here’s a fictitious scenario describing the above diagram:


     A – a user opens their web-browser and goes to MyPhotos.com which stores all of their photos.
    MyPhotos.com doesn’t handle authentication itself.
     B – to authenticate the user MyPhotos.com constructs a SAML Authnrequest, signs it, optionally encrypts
    it, and encodes it. After which, it redirects the user’s web browser to the Identidy Provider (IdP) in order to
    authenticate. The IdP receives the request, decodes it, decrypts it if necessary, and verifies the signature.
     C – With a valid Authnrequest the IdP will present the user with a login form in which they can enter their
    username and password.
     D– Once the user has logged in, the IdP generates a SAML token that includes identity information about
    the user (such as their username, email, etc). The Id takes the SAML token and redirects the user back to
    the Service Provider (MyPhotos.com).
     E – MyPhotos.com verifies the SAML token, decrypts it if necessary, and extracts out identity information
    about the user, such as who they are and what their permissions might be. MyPhotos.com now logs the
    user into its system, presumably with some kind of cookie and session.

    At the end of the process the user can interact with MyPhotos.com as a logged in user. The user’s
    credentials never passed through MyPhotos.com, only through the Identity Provider.

    OAuth 2.0

     Resource Server (Service Provider) – this is the web-server you are trying to access information on.
     Client – this is how the user is interacting with the Resource Server. This could be a browser-based web
    app, a native mobile app, a desktop app, a server-side app.
     Authorization Server (Identity Provider) – this is the server that owns the user identities and credentials.
    It’s who the user actually authenticates and authorizes with.
    At a high level, the OAuth2 flow is not that different from the earlier SAML flow:
     A – a user opens their web-browser and goes to MyPhotos.com which stores all of their photos.
    MyPhotos.com doesn’t handle authentication itself, so the user is redirected to the Authorization Server
    with a request for authorization. The user is presented with a login form and is asked if they want to
    approve the Resource Server (MyPhotos.com) to act on their behalf. The user logs in and they are
    redirected back to MyPhotos.com.
     B – the client receives an authorization grant code as a part of the redirect and then passes this along to the
    client.
     C – the Client then uses that authorization grant code to request an access token from the Authorization
    Server.
     D – if the authorization grant code is valid, then the Authorization Server grants an access token. The
    access token is then used by the client to request resources from the Resource Server (MyPhotos.com).
     E – MyPhotos.com receives the request for a resource and it receives the access token. In order to make
    sure it’s a valid access token it sends the token directly to the Authorization Server to validate. If valid, the
    Authorization Server sends back information about the user.
     F – having validated the user’s request MyPhotos.com sends the requested resource back to the user.
    This is the most common OAuth2 flow: the authorization code flow. OAuth2 provides three other flows
    (or what they call authorization grants) which work for slightly different scenarios, such as single page
    javascript apps, native mobile apps, native desktop apps, traditional web apps, and server-side applications
    where a user isn’t directly involved but they’ve granted you permission to do something on their behalf.
    The big advantage with OAuth2 flows are that the communication from the Authorization Server back to
    the Client and Resource Server is done over HTTP Redirects with the token information provided as query
    parameters. OAuth2 also doesn’t assume the Client is a web-browser whereas the default SAML Web
    Browser SSO Profile does.
    Native mobile applications will just work out of the box. No workarounds necessary.

    You might also like