How PeopleSoft Single Signon Works?

by Prashant on September 17, 2015

in PeopleSoft Basics

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
Also Read:  ChartField Request and Approval

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.

{ 5 comments… read them below or add one }

Ed Kelly October 9, 2014 at 10:20 am

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 March 25, 2015 at 3:16 am

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 October 16, 2015 at 1:58 am

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


endian May 5, 2016 at 6:27 am

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 September 10, 2016 at 2:10 am

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


Cancel reply

Leave a Comment

Previous post:

Next post: