title: Caveats for hardcoding a single OpenID provider?
body: <p>We're considering a few options for single-signon between our Django web application (we'll call it Website 1) and another specific website (Website 2). Our two top priorities are:</p>
  
  <ul>
  <li>Ease of implementation/maintenance.</li>
  <li>Avoiding the complication of our login process (our audience is not technically savvy at all). In other words, I don't want them to even know what OpenID is. They know to use their credentials from Website 2, though.</li>
  </ul>
  
  <p>There are tons of Django apps for OpenID, but we don't want our users selecting their provider (we want to force them to use their "Website 2" credentials). <strong>This is my primary concern: Can I hardcode the provider so they are always using "Website 2" as the authority?</strong></p>
  
  <p>Here's what my research so far seems to think would be the flow:</p>
  
  <ul>
  <li>User goes to the login page. We either display a button for them to click on to login, or
  we just say "We're going to redirect you to Site X for authentication" and do so after a few seconds.</li>
  <li>User gets redirected to Website 2. They enter their credentials and are redirected back to  us.</li>
  <li>The user doesn't know/care what just happened, and we have something simple to launch quickly.</li>
  </ul>
  
  <p>Am I on the right track? Is this even possible? Do you see any caveats?</p>