When I paste this URL (below) into my web browser... Chrome or IE
I get an error saying ...

Error! Do not use bookmarked URL.
Please type the URL you are trying to reach directly into your browser.

However, if I paste this URL into my browser (below)
then click the Sign In/Register link my browser takes me to the same URL (at top) but without an error.

My question is.. How can I go directly to this URL (https://login.oracle.com/mysso/signon.jsp) without having to go to some 'other' URL on the site first?

  • 24
    Why can't I go directly to the Oracle sign on page? Because Oracle
    – jimm-cl
    Mar 5, 2015 at 20:36
  • 3
    I bet that the sign in page works this way because there is no plain "You are now signed on" page. Instead, the sign in page needs to know where to send you. Mar 5, 2015 at 20:49

5 Answers 5


My first guess was that the page you are trying to access requires that a token be in place before it'll load correctly. It appeared that you could quickly register this token with the server and go to the page by following this link:


While that token may have been useful for other stuff. I've since found that it is not actually needed. By looking at the headers that this link caused to be posted I was able to determine that I would be able to duplicate the results of (most of) what happened when you followed that link by simply creating this HTML form to do the post for me:

<title>Oracle SSO</title>
<form method=post action="https://login.oracle.com/mysso/signon.jsp">
<input name=site2pstoretoken value="v1.2~656BF073~512EDAC9FEA5F9140AE8A612213BCA280B4FF70D159812B6FDF2EB8D5CA98482EB385D4542873325FB366CCD4F17E21E1329A9531F844D92AC97A70A8287652D76277798A2DDF3D738EAB735E756B24FFDF89DC77C46F81AE712DB7D4F3A0CAF8EB1AE708C04FC58FEAC6D44A4DCCA81BD967FA1AD32ED298B5563DABC10443620E45DC539A7F6E5A5AB22A2F7541EF9B3339AFE4EBBC920989B7E7556B3B6DBF84FA7643382B2907A6183D06FDD9E1358A534083E4B73A5FB6BA840A981AE3A41BF878240DA4C48C74765E10DF30AC91057225CDC77C9241409FE189D251B2EAFF14E9776ADDC3C81541F53CFFC745A1A93DFAAD06B496B5630E1A725266B84DA43FEB216463D4C89A6164441B7CEFC600CC991B549A52BC45550156A365C699CF8A89250427BA9" />
<input name=v value="v1.4" />
<input name=p_submit_url value="https://login.oracle.com:443/sso/auth" />
<input name=p_cancel_url value="http://www.oracle.com" />
<input name=p_error_code value="" />
<input name=ssousername value="" />
<input name=subscribername value="" />
<input name=authn_try_count value=0 />
<input name=contextType value=external />
<input name=username value=string />
<input name=contextValue value="/oam" />
<input name=password value=sercure_string />
<input name=challenge_url value="https://login.oracle.com/mysso/signon.jsp" />
<input name=request_id value=-4782010454026398257 />
<input name=OAM_REQ value="VERSION_4~VeXlMi8vRU%2fhyhTAezfX%2fU92tvWZdduOvqF%2b%2fZcYUDnWrzu4V%2fcd4uyZvxIJbR7IxaYlaMA0wEkYKHSaDT5s7MPlYk3PRIlWNYxRTtYnK0kS2JQZrKDOL4CStRvsWAbuaMQJepMzUvRrxCEamyAH0sRT5caX3lCeI1iS7znsSTNIOXOl%2fgzOIoCD4JTPfO6WAbGiW3HdRBx5Y%2bDUrjsA%2fTPURYUU%2bXZ2XpPD%2fzWu11oXQV9C9lR36H8x97UkYcjyjtT%2b9vdHp8a0QwbAxG26N4eDokGnz5MRKaILo%2bsm2itImqCAlaTDWPBhTisfT89Av8Vv6FYAG%2bUDwj1BtTpshXinS0YHDwGAGYK7GB1VIeXraYIhR7V7C92H7dMGl8j%2fNof7JiN%2fjPEIRLjnX%2fgWNqNRzRaJe%2be7LVUrbOfGkvr2l%2fuAtYhY%2b9Q%2b2QvyHp%2bESS4Mnt4We6TdZ7Ap4zQbV3ZWh2f8vbBJYSw25R77Q2JatsjQQCJnAbKtwKwmauNHZgdo8yeeq7KZoltgciAZq9cm34CgQ3IburhracegH%2bFc9jV%2fnfu8BknpoIAjgDOdxtguYtoQpKitkwCGsQLPm9oaxE0n8wbJLWta2Vj7RLh5HmF7Za%2btda6t%2fW9MweMWiq66MvGZtDIa8pNycALi4SHtfp1SiVlhABeuVftbaoM%2fDStyjbPEUXEJBxLVYOiMODjov0GtsD5ZTzP9NH39ata8fZvHjyXUxTgZmhJQsZPH4r5ks2cz2tV%2bpw5Gb4U2Wvl81iXlVcSfiwGSp55qs9xSbJkQkBl9eagNO20RsKBI9W9KNTo3Boku5SMVOTt%2bsPPXwiiJlkblq2Jn7GLhDX8oFH36XsSlo%2bIPqWfCgaesTXyYnnsfK%2b2u8uByuRvDy6XCuj6O0ytLp8sKhFNAGZq1JVhIrh5%2bgxiLkZ%2bL2SVVV1HsP2TweR9WkFvytSgdx06NPrNvDJKFGvlV%2f8428uz5cCAUF5cr%2bX%2fiQ42EwsF3iZF1nQcHqcF44v7CBYYGuAW%2fDr9ojnrjj%2bT6dstOScY1vjLXIpgQs83wsbc1KfA26907E42yEgV5sPexC452gIPvcq4rLRr8Hm4hhWXnMxF1kX2zZnruo7yldr2VIT%2bUy11ZT4mcW7AgSipQaTkmbOgtv3nuvipoiGq9AeEzz%2fyUQurw2BSXcsP4HgMPO2cA5G93%2bBsT90gNEiQySyDwbJShjEVrCfry6a00zDzKXaddOAzinHOe7zHXJSbSoeqOw1XzS3bv8G7gcS3XNGa3yOUP%2fhHcNdpxqa%2bwbsEag9xKvCJRxr5Zr8GZK2GWu5XU8Kx9j6XiIQtsU1%2bl8p1AaP%2bCuKFgXz6gK2YePb6DPYmhyasplXtq569ytFdaD5NOgUN2CeRqjdxoKTOlyZWfr6bNZf1hI0sYUT8FlP0O%2fQ%2bi65j2zRBKPiosOsGNwnzbDOLcF1bZfJCmOL5u6cx8QJXe2VFQewIcC%2fvt8CMFDKwz82N%2bxtYkhMs%2fj2GmACcHeuTPBNnRjAO059S6mE3FMf0hFfLarLbGW6uLCiV%2bWKPq7f6FqIAYy73e%2fW5yd6RtajzaLaA14fd2AIx62WqTCLTbQTMwDBG2Y966dZvyQwzEmfNVWp317NB%2byvdM0HE0bPKlPHs5IVPGBSBPgSPc4ICqTMprlj%2fapVfQT5cDa2m%2fqyo6Z2Rhj19uyJwzSoX4Ib%2bMP3q90E6SqligrDKxFtCDIa2Kc3As9F8sDhU7%2bgvYXX%2bABP1GAGFtlDhq%2fA4vq%2bkD4%2bIFtq2hg1svtuPA7YwajG5z1ZZF1EsZqbKCZKCe8nJKe2GZDf3miXR1%2fAZgTnjmaks7vTHwkB9k48YNomqgSBsqPSOYRNVOIYrKPsKeRMf6xvKCpEl6Whst5E1BsT1zWl6WZPhcn%2f0ABsl%2b5AUtZ%2bvKqI%2fyymq1zOidcpn6Ao%2bO55wSAj%2botPbUr1UyrQbMFlV7jWJPYOs%2bicDSRf1DZlC1w5rsIUz7HRAjVcc4yyRnTwOeGXnoUTuzoHJ5PhmxpBIbr0otlfiDMHY6cm960PvYDAtWUSgOnwA4%2bPtY4YtmBSZuvSrk3W7L%2f1%2fTaYGb0uccJx1sfB6qwD1Isk80NxnKWCCftv0W0AE3zf9xpei1SWNp%2fMJH1yfpVFM%3d" />
<input name=locale value=en_US />
<input type="submit" value="Submit">

As you can see, the referrer is not critical here. All that matters is that the login form is given the information contained in the setup form. I still don't know where to get those tokens aside from the main site though, you'll need to figure that out yourself.

After playing around with this a little more, I found out that the only value on the form above which matters is the request_id. The following, much simpler, version could be used:

<title>Oracle SSO</title>
<form method=post action="https://login.oracle.com/mysso/signon.jsp">
<input name=request_id value=-4782010454026398257 />
<input type="submit" value="Submit">

What's more, the form will accept this value as either a GET or a POST. Meaning, that you can access the form at: https://login.oracle.com/mysso/signon.jsp?request_id=-4782010454026398257

This makes things much easier. Now, you just need to find out whether or not you'll need to keep a fresh request_id around or if that one will last forever. It may not even matter what request_id you use. I don't have an account on that page (so I can't test this) but if I enter ANY number for the request_id it displays the form. Try logging in with a number you just make up like this:


or with even no id at all, like this:


I haven't actually tested this beyond the fact that this will make the form display. Read the comments to see if anyone else has.

  • I see that the link does indeed work 'at the moment' anyway. I have no idea how to create these token(s). I suppose I'll need to navigate some 'other' page on the site first.
    – Rose
    Mar 5, 2015 at 17:30
  • 2
    I don't think you'll ever be able to create them. To get them, go to oracle.com/webapps/redirect/signon and let it redirect you to the login page. Then you can find the token in the post headers sent to that page. In chrome this can be seen by pressing Ctrl+Shift+J and using the 'Network' tab to catch it.
    – krowe2
    Mar 5, 2015 at 17:35
  • This should be enough information that you could automate this entire process if needed. It'd take some more work to put it all together though.
    – krowe2
    Mar 5, 2015 at 17:38
  • @Suzy See my update.
    – krowe2
    Mar 5, 2015 at 17:46
  • 4
    Nice detective work
    – Floris
    Mar 5, 2015 at 20:09

They're doing some weird black magic based on the Referer header, which contains the URL of the previous page, if any.

Basically if the referer is present and set to another one of their pages, all is fine, otherwise they throw an error. Only they can explain why they're doing this.

This may be an attempt at increasing security, but to me this looks like a security theater as bookmarking the genuine URL seems more safe than typing and possibly mistyping the domain, which would then allow an attacker to register the mistyped domain (oralcle.com for example) and put up a phishing page.

  • 2
    I would agree its security theater. Any security concerns can by squashed by using a password manager.
    – Ramhound
    Mar 5, 2015 at 17:15
  • 1
    @Ramhound but in this case they're forcing you to do so (and even then they're flat out lying, as accessing the site by tying the URL doesn't set any referer header and thus displays the error page).
    – user256743
    Mar 5, 2015 at 17:16
  • 6
    It probably has nothing to do with security but with using a shared login service. There are probably multiple equally valid places to drop you after you authenticate, but none making any more sense than another, and all making zero sense under different use cases. As such, they are likely trying to make you type in the intended location so that the result of logging in is a redirect to an appropriate location. For usability and functionality. Not for security.
    – atk
    Mar 5, 2015 at 19:15

It is a "single sign on" system. The domain login.oracle.com only allows you to authenticate, but has no content on it's own. Thus, if you don't come from another domain which required you to log in, it would show you no content at all.

As there is no content at that domain and your favourites does not include any info of what you were trying to access, they just warn you that your favourite is pointing to the wrong address.

After login in and for the session duration, you may access any subdomain at oracle as an authenticated user without the need to log in again in.

It's like you usually work with google: you must login at accounts.google.com, but you usually access it using other domains (www.google.com, mail.google.com, etc)


It's likely to be a centralized identity provider, which might be used by multiple systems. It looks like it's using Oracle Application Server SSO. I'm not familiar with that specific product, but such a system might look like this:

  1. User accesses target site.

  2. The target site redirects to the user to the login server. The redirect includes a token which provides details about the original request. (The referer header could also be used, but it would make it harder to handle cases where the initial request was a POST instead of a GET request.)

  3. The login server accepts the token, recognizes that the user isn't yet signed in, and prompts them to log in.

  4. The user logs in to the login server.

  5. The login server returns the user to the originally requested resource, providing information about the original request and the user's identity back to the application.

  6. The application recognizes and trusts the identity assertion provided by the identity provider, so it handles the original request.

One advantage to this system is that the identity system is less coupled to the application consuming the SSO services. The identity provider is responsible for authenticating users, so individual applications don't have to be concerned with the mechanics of authenticating users.

An organization could also make large changes to the authentication process without each application having to be reconfigured for the new method. This could mean enhancing password-based logins with an RSA key fob, switching to Windows Integrated Authentication, moving users from a legacy LDAP system into Active Directory, and so on.

If multiple applications use the same identity provider, then you also get the benefit of single sign-on. This means that once you've logged in to one application, the process for accessing another integrated application becomes:

  1. User accesses target site.

  2. The target site redirects to the user to the login server. The redirect includes a token which provides details about the original request. (The referer header could also be used, but it would make it harder to handle cases where the initial request was a POST instead of a GET request.)

  3. The login server recognizes the user from the existing session. It returns the user to the originally requested resource, providing information about the original request and the user's identity back to the application.

  4. The application recognizes and trusts the identity assertion provided by the identity provider, so it handles the original request.

Note that since the user is already logged in to the identity provider, all that they'll experience is a few quick redirects.


I had the same issue, try this URL instead https://profile.oracle.com/

  • 1
    Please add further details to expand on your answer, such as working code or documentation citations.
    – Community Bot
    Aug 31, 2021 at 12:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .