I recently research the SSO solution, and I went into the OpenID connect framework; but after several days of research, this makes me confused that the 'OpenID Connect' protocol does not define the flow for how to login into a Authroization Server and The server how to identify a user will be the user who is coming in ? But according to the official document that the OpenID Connect's purpose is just for Authentication ?

So, anybody could give me some suggestions that if it is possible by using openid connect to meet my purpose:

  1. If i want to implement a Identity Provider server, then how to deal with the user login processes(After user click the login button)?

  2. And, if i want to implement the SSO, then anything else i should do?(just some suggestion)?

B.T.W , my company will provide the different kinds of device products(like , ios ,android,html5 app), but all the products need to login from one server(SSO)

  • Welcome. I tried to give a sens for some of your phrases (introductive paragraph) but I can not. So may be you can clarify that? Also, questions 1 and 2 are too broad to answer. Question 3 is banned here because product recommendations are off-topic questions.
    – user45139
    Aug 19, 2015 at 4:55
  • remove the 3 question, and add more comments for it, this thread is just for inquiry, The people can reply me at the high level.
    – Kris
    Aug 19, 2015 at 5:21
  • Can you please edit your question to reword this phrase: This makes me confuse what OpenID connect is not define...?
    – user45139
    Aug 19, 2015 at 5:23
  • Could you check , i am sorry my english.
    – Kris
    Aug 19, 2015 at 5:27

2 Answers 2


First, you need to understand that OpenID connect is built on top of OAuth 2. That is, you need to understand the differences of the Authorization server, the resource server, the client and the user.

In general the idea is:

  1. a user wants to use a client application but he/she has to login first
  2. the client application trusts an authorization server,
  3. the authorization server knows the user, and asks him/her about the data he/she wants to share with the client application,
  4. if you allow to share the data, the authorization server responds to the client application with an id_token
  5. The client application now can verify the id_token and check the user information contained inside (such as user_id, first_name, last_name, etc.)
  6. the client application now allows you to access (knowing who the user is)

The flow can be slightly different if you are using authorization code or implicit grant, but that should give you a rough idea.

If you are the one implementing the identity provider and/or authorization server then you must allow a client application to be able to register himself in your system. Usually this includes, name of the client and redirect urls to respond when the user clicked login.

hope it helps,

  • Hi, Jorge, Thx your reply, there is one more question is about how to judge a user has logined will mainly according to the session ,right ?
    – Kris
    Aug 19, 2015 at 8:08
  • yes, you probably need a cookie (persistent or not) in order to find out if the user is already logged-in. If you cannot find the cookie in the request then you must show your login page, set the cookie and proceed with the authorization page. Aug 19, 2015 at 8:11
  • B.T.W, if the user is using an andorid/ios devices then we need to mananage both session&access-token and to deal with the redirect(302) forward manually?
    – Kris
    Aug 19, 2015 at 8:34
  • Sorry, There is another things, if a user access the resource endpoint of himself, that means he should also use the access-token right ? because the resource server will filter every endpoint uri and authentication it from authorization server by access-token.
    – Kris
    Aug 19, 2015 at 8:47
  • yes, you have to know if the user is logged in, but that depends on your implementation, cookies or sessions, and usually it is independent of the platform. if the endpoint only works with access tokens then it's not supposed to work with users but with client applications Aug 19, 2015 at 10:48

The most common use case for SAML and OpenID Connect (which are largely parallel) is cross-domain SSO. SSO is achieved by tracking a browser with an application cookie. So technically, that happens outside the OpenID Connect and OAuth specifications. But it is not wrong to say that OpenID Connect is a means for achieving SSO with web and mobile applications--that is basically what everyone is using it for.

  • Doesn't having an ID token eradicate the need of a session cookie? Nov 20, 2019 at 19:35

You must log in to answer this question.

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