How PeopleSoft Single Signon Works? | PeopleSoft Tutorial

How PeopleSoft Single Signon Works?

Single Signon refers to the ability of users to navigate freely within a system of multiple applications after only being authenticated once.

It means that user will be asked for his/her login details only once and whenever he/she clicks on a link pointing to other application, then security information is passed from one application to other automatically and there is no additional burden on user to enter login details again. Of course, all these participating application should have Single Signon configured.

Oracle PeopleSoft application can be configured to participate in Single Signon and there are 3 options available:

  1. PeopleSoft Only  [PS_TOKEN Cookie]
  2. PeopleSoft and Oracle Apps
  3. PeopleSoft and Kerberos

In this post, we will discuss about ‘PeopleSoft Only’ Single Signon Implementation and how 2 PeopleSoft applications participate in a Single Signon Setup.

Before we start with the functionality and setup of Single Signon, we should learn a little bit about PS_TOKEN cookie.

What is PS_TOKEN cookie?

PS_TOKEN is a cookie which is embedded into the browser memory of a user authenticated by the PeopleSoft Web Server. As long as cookie is active, user can browse that PeopleSoft Application without entering login details again.

Note: If cookies are disabled in your browser, user won’t be able to get into PeopleSoft Application.

How is PS_TOKEN cookie generated?

When a user enters his/her login details in PeopleSoft application, Webserver passes that information to PeopleSoft Application Server. Based on the information provided, PeopleSoft Application Server performs following tasks:

  • Authenticates the user
  • Generates a Single Signon Token
  • Encrypts the Single Signon Token
  • Sends the token to Webserver with a code indicating that system authenticated the user

Single Signon Token generated by Application Server contains user id, language code, date and time when issued , issuing system and the signature.


Signature is created after encrypting the combination of first 4 values and local node password.

Signature = SHA1_Hash ( User ID + Language Code + Date and Time Issued + Issuing System + Local Node Password )

After receiving Single Signon Token from the application server, PeopleSoft Web server generates the PS_TOKEN cookie and then inserts it into user’s browser memory.  Data value of the PS_TOKEN cookie contains the Single Signon Token generated by the Application Server.



PS_TOKEN cookie remains in the user’s browser until the session expires.

How Secure is PS_TOKEN Cookie?

PS_TOKEN cookie authentication is considered to be very secure and has few security features.

  • PS_TOKEN cookie resides in browser memory and never written to disk
  • No Passwords are stored in the cookie
  • Encrypted
  • Contains Digital Signature
  • Cookie becomes invalid after set expiration time

There are few security concerns related to encryption and non-standard algorithm used in generating PS_COOKIE  which may lead a hacker to forge PS_TOKEN. You can read more about it in this article.

How PeopleSoft Only Single Signon Works?

Now that you understand the generation of PS_TOKEN cookie, lets focus on Single Signon process between 2 PeopleSoft Applications. Consider 2 applications to be HCM and FSCM where user first logged into HCM (which will generate PS_TOKEN).

While browsing through HCM application when user clicks on a link pointing to FSCM application, below is series of steps that will occur:

  1. Browser sends the PS_TOKEN cookie(generated by HCM) to FSCM Web Server.
  2. FSCM Webserver sees signon token and doesn’t display sign in page , instead it sends the DATA field of PS_TOKEN cookie to FSCM application server for authentication and validation.
  3. FSCM application server performs the validation checks on DATA field of PS_TOKEN cookie.
    Check 1:  Is forwarding node trusted ?Issuing system value in the DATA field should be a trusted node in FSCM application with an entry in PSTRUSTNODES table.
    Check 2: Has Token Expired? – Checks Issued Date and Time Value to see if the token has expired. Expiration value set in FSCM is checked instead of value set by HCM application. If HCM has a expiration value of 40 minutes and FSCM has a expiration value of 20 minutes, then value set under FSCM (20) is considered for this validation check.
    Check 3: Signature Tampered? – Using the info in the token, FSCM app server generates a signature and then matches it with the signature present in the token. Both needs to be a perfect match.
  4. After all the validation checks are passed, FSCM application server provides the information requested by the user.

  • Ed Kelly says:

    Hi Prashant

    I just read your article regarding the Single Signon Token. You seem very proficient on this topic. Have you ever come across an issue where a user will randomly obtain the identity of another user? I have seen this. The appserver logs will state a switchuser has taken place. Sometimes this might be preceded by a jolt error or an appserver recycle is sometimes part of the equation, but I cannot recreate the error on a consistent basis. Are you aware of any bugs in tuxedo that may cause this issue? Maybe active users are not gracefully handled during a recycle? Or maybe a webserver bug where by a user gets linked to the wrong webserver session and inherits another users cookie or something of that nature.

    Any thoughts on this topic would be greatly appreciated.
    Thanks for any suggestions

  • ST says:

    Hi Prashant,

    Thanks for writing the article. I also saw same issue as Ed mentioned above but no idea.

    Would you shed some light on us ?
    Thanks a lot.

    /ST Wong

  • kaushik says:

    what is the resolution for this issue?
    how do we improve perfomance in single signon

    what are the steps for implementation in single signon.?

    Do’s and Don’ts.

    Can you please mail to

  • […] Prashant Tyagi on PeopleSoft Single Signon (118) […]

  • endian says:

    Well, the PS_TOKEN brute force code just made it into John the Ripper and olHashCat…

    At least the token is never written to disk, so I have that goin’ for me.

  • Gopinath says:

    how do we improve perfomance in single signon

    what are the steps for implementation in single signon.?

    Do’s and Don’ts.

    Can you please mail to

  • Miller says:

    Hello Prashant, Great article on PeopleSoft.Thanks for ur effort. Keep updating the blog always..
    Any idea about:  My client wants to implement SSOgen for PeopleSoft..
    Thanks a lot!

  • Narender says:

    Hi Prashant,

    Thank you for the Single signon Article.

    Do you have implemented external SSO authentication for peoplesoft like PingAccess. If you have any similar documentation is available it will be more helpful for me as my customer looking into implementing PingAccess SSO authentication for peoplesoft.

    • Rakesh Maheshwari says:

      Has anyone implemented Ping Identity for Single Sign-on (SSO)? We current do using CA SiteMinder but need to migrate to PING Access. We are currently running into challenges (PeopleSoft Sign-on code not executed) while trying to do using Ping Access. Below is our environment info

      PeopleTools 8.57.06
      Oracle Proxy Weblogic Plugin installed on Apache Server
      Weblogic 12.2.x Webserver

      Any help is greatly appreciated.

      • Garima says:

        Hi Rakesh,

        Could you please provide the details of the SSO solution using the CA Siteminder? We are planning to use CA Siteminder to implement SSO for PeopleSoft.


  • >