Openam social authentication queries

This topic has 3 replies, 2 voices, and was last updated 5 years ago by Peter Major.

  • Author
  • #18313

    Hi All,

    I am trying to understand more on the OpenAM social authentication flow on web applications level. If we consider the facebook authentication flow, below are the keys steps,
    1) User requests the authentication using the Oauth2.0 module
    2) OpenAM send the request to authorization service at Oauth2.0 provider using a redirect through the user agent (browser). The request containing the client_id, redirect_uri, and scope for authentication module
    3) Oauth 2.0 provider establishes whether user grant access or not, checking whether user is already authenticated, if not user is authenticated
    4) if your grants access to the request from openam, the auth 2.0 provider sends the authorization code to openAM via redirect (browser)
    5) OpenAM request access token from Oauth 2.0 provider using the client_id, client_secret and authorization code received from Oauth2.0 provider earlier
    6) The Oauth2.0 provider validate the credentials and authorization code, then return an access token to openAM
    7) OpenAM uses the access token to request user profile informations such as the email address and map it with local user store if the module has been configured so
    8) The authentication module success, and openAM provides the sso token.
    Here I have few queries.
    1) Where exactly the access token and refresh token getting saved?
    2) The Facebook authentication creates the authid and NTID cookies, what are the values embedded here?
    3) When a user re-authenticate using facebook module ( scenario like User logged in using facebook module > landed to user session page > user calls logout (iplanetdirectorypro removed) > user try to re-login > user select the facebook authentication > user landed to final page without submitting credentials). Can someone tell me hows the flow happening at the back-end?

     Peter Major

    1) access token is saved in a session as a property, AFAIK refresh tokens aren’t stored by the authentication module.
    2) The authid cookie tells OpenAM where to continue the authentication when the user comes back from the authorization server. The NTID cookie stores a lookup key which the authentication module will later on use to look up the expected state and nonce parameters so that the authorization code response can be validated.
    3) if you are logged out on the AM side, then pretty much the same thing happens. The user gets redirected to the authorization server, the AS determines that the user is already logged in and has already authorized access for the remote application, hence it just sends back the authorization code to OpenAM.


    Hi Peter,

    Thanks for the reply, can you please elaborate the point 3? How exactly OpenAM identifies that the user was previously logged in? What are the cookies used here? it will be great if you can split the steps by point.

    Thanks a lot in advance

     Peter Major

    Your question makes no sense I’m afraid. OpenAM does not identify whether the user was previously logged in. It’s the authorization server that authenticates the end-users, not the OAuth2 client (which is OpenAM in this scenario).

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?