By: Franz Noel Tanglao user 29 Sep 2016 at 2:30 p.m. CDT

27 Responses
Franz Noel Tanglao gravatar
I have saved my client_secret to `~/.pw`, and ran the command: /opt/opendj/bin/ldapsearch -h localhost -p 1636 -Z -X -D "Cn=directory manager" -j ~/.pw -b "o=gluu" -s base 'inum=@!B190.F04D.5DCA.D6B3!0001!CC4E.B109!0008!425D.A5A0' I get the following results: The simple bind attempt failed Result Code: 49 (Invalid Credentials) The reason why I did above is because I get 401 Unauthorized. When doing: POST https://gluu-srv.example.com/oxauth/seam/resource/restv1/oxauth/token ?grant_type=authorization_code &code:<code> &redirect_uri=<redirect_uri> &client_id=<client_id> &client_secret=<client_secret> Currently, it gives me an `invalid_client` error. Is there any other things in the GLUU Server that I should change to make it authorize? **Update**: I registered another OpenID Client with the same password. Then, ran the same LDAP test. I still get `Result Code: 49 (Invalid Credentials)` I made sure that I was locally inside the GLUU container. What is going on, and how do I make the credentials work?

By Aliaksandr Samuseu staff 30 Sep 2016 at 11:37 a.m. CDT

Aliaksandr Samuseu gravatar
Hi, Franz. You lost me here. What are you trying to achieve by running this LDAP search, and how it's connected to OpenID client you created? In any case >Result Code: 49 (Invalid Credentials) just means your credentials are not correct. As you are using "Cn=directory manager" as bind DN, you should provide your default LDAP password that was created during running `setup.py` script (or was provided to it by you perhaps). Is that what you do?

By Franz Noel Tanglao user 30 Sep 2016 at 1:36 p.m. CDT

Franz Noel Tanglao gravatar
After playing around with LDAP, I found out that `CN=directory manager` has a password. So, I tried this query to give me the results: /opt/opendj/bin/ldapsearch -h localhost -p 1636 -Z -X -D "Cn=directory manager" -W ~/.pw -b "o=gluu" -s sub '(inum=@!B190.F04D.5DCA.D6B3!0001!CC4E.B109!0008!425D.A5A0)' Here are my results: dn: inum=@!B190.F04D.5DCA.D6B3!0001!CC4E.B109!0008!425D.A5A0,ou=clients,o=@!B190 .F04D.5DCA.D6B3!0001!CC4E.B109,o=gluu objectClass: oxAuthClient objectClass: top oxAuthScope: inum=@!B190.F04D.5DCA.D6B3!0001!CC4E.B109!0009!10B2,ou=scopes,o=@!B 190.F04D.5DCA.D6B3!0001!CC4E.B109,o=gluu oxAuthScope: inum=@!B190.F04D.5DCA.D6B3!0001!CC4E.B109!0009!43F1,ou=scopes,o=@!B 190.F04D.5DCA.D6B3!0001!CC4E.B109,o=gluu oxAuthGrantType: authorization_code oxPersistClientAuthorizations: false oxAuthPolicyURI: https://demo.dev/policy oxAuthLogoutURI: https://demo.dev/logout.php oxAuthLogoutURI: https://demo.dev/sign-out.php oxAuthResponseType: code oxAuthTrustedClient: true oxAuthAppType: web oxAuthLogoutSessionRequired: true oxAuthTosURI: http://demo.dev/terms oxAuthSubjectType: pairwise oxAuthClientSecret: <Secret Key shows up here> oxAuthClientURI: http://demo.dev oxAuthTokenEndpointAuthMethod: client_secret_basic oxLastAccessTime: 20160929235256.510Z oxAuthIdTokenSignedResponseAlg: HS256 oxAuthRedirectURI: http://demo.dev/oauth-login.php oxAuthRedirectURI: https://dev.example.com/oauth-login.php displayName: Song App inum: @!B190.F04D.5DCA.D6B3!0001!CC4E.B109!0008!425D.A5A0 I realized that the `Secret Key` could have been hashed differently from the password I entered. **Other things that I learned:** The token should be requested from a Client Application or Web API with `SSL` settings requiring it to have `HTTPS`.

By Franz Noel Tanglao user 30 Sep 2016 at 3:09 p.m. CDT

Franz Noel Tanglao gravatar
> You lost me here. What are you trying to achieve by running this LDAP search, and how it's connected to OpenID client you created? I was trying to connect using OpenID and OAuth2, but it gave me `Result Code: 49`. The LDAP query: /opt/opendj/bin/ldapsearch -h localhost -p 1636 -Z -X -D "Cn=directory manager" -j ~/.pw -b "o=gluu" -s base 'inum=@!B190.F04D.5DCA.D6B3!0001!CC4E.B109!0008!425D.A5A0' Does not prompt for a password: LDAP setting password or API Secret Key. So, I used `ldapsearch` to find out and verify what my `API Secret key` is using this query: /opt/opendj/bin/ldapsearch -h localhost -p 1636 -Z -X -D "Cn=directory manager" -W ~/.pw -b "o=gluu" -s sub '(inum=@!B190.F04D.5DCA.D6B3!0001!CC4E.B109!0008!B573.E000)' Later on, I found out that it was hashed after entering my GLUU setup password. So, I got the correct `API Secret Key` and it worked.

By Michael Schwartz Account Admin 01 Oct 2016 at 3:11 p.m. CDT

Michael Schwartz gravatar
I think this is related to another issue, but for some reason Franz opened a new ticket. ``` oxAuthRedirectURI: http://demo.dev/oauth-login.php ``` This is an invalid redirect_uri. The OpenID Connect spec requires `https` ``` oxAuthSubjectType: pairwise ``` I'd recommend public. Pairwise returns a different subject identifier for each client. Per my note: '-j ~/.pw` requires you to enter the LDAP Directory Manager password in the file `~/.pw` Is this issue closed? Should we also close the previous issue?

By Franz Noel Tanglao user 04 Oct 2016 at 12:13 p.m. CDT

Franz Noel Tanglao gravatar
I have been able to install SSL successfully. However, I can't seem to get the token still. **First request** GET https://gluu-srv.example.com/oxauth/seam/resource/restv1/oxauth/authorize?scope=profile&response_type=code&client_id=@!B190.F04D.5DCA.D6B3!0001!CC4E.B109!0008!425D.A5A0&redirect_uri=https://demo.dev/oauth-login.php Without using a libray, but just using using JavaScript, in `oauth-login.php`, this is the code: 'use strict'; var token = $("#token"); fetch('https://gluu-srv.example.com/oxauth/seam/resource/restv1/oxauth/token',{ method: 'post', headers: { 'Content-Type':'application/x-www-form-urlencoded' }, mode: 'cors', body: { code: '<?php echo $_GET["code"]; ?>', client_id: "<?php echo CLIENT_ID ?>", client_secret: "<?php echo CLIENT_SECRET ?>", redirect_uri: '<?php echo SITE ?>/data.php', grant_type: "authorization_code", } }).then(function(response) { console.log(response); return response.json(); }).then(function(json_response) { var html = '<div class="alert alert-danger">'; html += '<h3>Status: ' + json_response.error + '</h3>'; html += '<p>' + json_response.error_description + '</p>'; html += '</div>'; token.html(html); console.log(json_response); }).catch(function(response) { console.log(response); }); **Second request** (can be translated as follows) POST HOST: https://demo.dev Content-Type: application/x-www-form-urlencoded code={code}&client_id={client_id}&client_secret={client_secret}&redirect_uri=https://demo.dev/data.php&grant_type=authorization_code I checked my settings: dn: inum=@!B190.F04D.5DCA.D6B3!0001!CC4E.B109!0008!425D.A5A0,ou=clients,o=@!B190 .F04D.5DCA.D6B3!0001!CC4E.B109,o=gluu objectClass: oxAuthClient objectClass: top oxAuthScope: inum=@!B190.F04D.5DCA.D6B3!0001!CC4E.B109!0009!10B2,ou=scopes,o=@!B 190.F04D.5DCA.D6B3!0001!CC4E.B109,o=gluu oxAuthScope: inum=@!B190.F04D.5DCA.D6B3!0001!CC4E.B109!0009!43F1,ou=scopes,o=@!B 190.F04D.5DCA.D6B3!0001!CC4E.B109,o=gluu oxAuthRequestURI: https://demo.dev/data.php oxAuthGrantType: authorization_code oxPersistClientAuthorizations: false oxAuthPolicyURI: https://demo.dev/policy oxAuthLogoutURI: https://demo.dev/logout.php oxAuthLogoutURI: https://demo.dev/sign-out.php oxAuthResponseType: code oxAuthLogoutSessionRequired: true oxAuthAppType: web oxAuthTrustedClient: true oxAuthTosURI: http://demo.dev/terms oxAuthClientSecret: 1SdyFn8TdsEdegfeyVAE1r/Y463q5v8GcnKWpqXuuRyMPPtYzZXjrQ== oxAuthSubjectType: public oxAuthClientURI: http://demo.dev oxAuthIdTokenSignedResponseAlg: HS256 oxLastAccessTime: 20161004165146.891Z oxAuthTokenEndpointAuthMethod: client_secret_post oxAuthRedirectURI: https://demo.dev/oauth-login.php displayName: Song App inum: @!B190.F04D.5DCA.D6B3!0001!CC4E.B109!0008!425D.A5A0 Still, I get `401 invalid client` error. This is the error I'm getting in the first console.log: Response { type: "cors", url: "https://gluu-srv.example.com/o…", status: 401, ok: false, statusText: "Unauthorized", headers: Headers, bodyUsed: false } oauth-login.php:91:17 Error in the second console.log: Object { error: "invalid_client", error_description: "Client authentication failed (e.g. …" } Is there any other settings that I need to change? Why am I getting `invalid_client` error

By Michael Schwartz Account Admin 04 Oct 2016 at 12:18 p.m. CDT

Michael Schwartz gravatar
I don't think you can put client_secret in the url... Is this server or client side javascript?

By Aliaksandr Samuseu staff 04 Oct 2016 at 12:27 p.m. CDT

Aliaksandr Samuseu gravatar
Hi, Franz. In your second request you provided, you use `redirect_uri=https://demo.dev/data.php`, while in your client's configuration (and in your 1st request) it's ``` oxAuthRedirectURI: http://demo.dev/oauth-login.php oxAuthRedirectURI: https://dev.example.com/oauth-login.php ``` I.e., nothing with `data` in it at all. Could you verify your settings once more?

By Franz Noel Tanglao user 04 Oct 2016 at 1:01 p.m. CDT

Franz Noel Tanglao gravatar
Hi Michael, I was basing my POST in Google documentation. It is a client side Javascript: https://developers.google.com/identity/protocols/OpenIDConnect#exchangecode I have added Login Redirect URI: `https://demo.dev/oauth-login.php`, and changed the redirect to use `oauth-login.php`: fetch('https://gluu-srv.example.com/oxauth/seam/resource/restv1/oxauth/token',{ method: 'post', headers: { 'Content-Type':'application/x-www-form-urlencoded' }, mode: 'cors', body: { code: '<?php echo $_GET["code"]; ?>', client_id: "<?php echo CLIENT_ID ?>", client_secret: "<?php echo CLIENT_SECRET ?>", redirect_uri: '<?php echo SITE ?>/oauth-login.php', grant_type: "authorization_code", } }) Then, I tried to get the token again by logging in. It still seems to be giving me `invalid_client`.

By Michael Schwartz Account Admin 04 Oct 2016 at 1:26 p.m. CDT

Michael Schwartz gravatar
If you are using client-side JS, you should be using implicit flow: `response_type` either: 1. id_token token 2. id_token Then you will not need to supply client_secret in the URI, which is not even supported in OpenID Connect (basic, post or jwt is only supported...). Also, Alex is quite right about the `redirect_uri`. As there is no `client_secret`, the only security is pre-registration of the `redirect_uri`. So this must be an exact match. I suggest finding an OpenID Connect library if possible. There are a lot of places to go wrong

By Franz Noel Tanglao user 04 Oct 2016 at 3:02 p.m. CDT

Franz Noel Tanglao gravatar
Using the client side JavaScript with a simple GET: GET https://gluu-srv.musicreports.com/oxauth/seam/resource/restv1/oxauth/authorize?scope=profile&response_type=token id_token&client_id=@!B190.F04D.5DCA.D6B3!0001!CC4E.B109!0008!425D.A5A0&redirect_uri=<?=SITE?>/oauth-login.php I get the following response: https://demo.dev/oauth-login.php#error=invalid_request&error_description=The+request+is+missing+a+required+parameter%2C+includes+an+unsupported+parameter+or+parameter+value%2C+or+is+otherwise+malformed. I followed the required parameters given here. https://www.gluu.org/docs/api/oic-authorization/ But it doesn't give me the correct results. I know I've read some of the Support information, and I know I've gone far this route, but if the **Open ID is not enabled from the setup**, would it still work using SCIM? I notice that **the Admin UI uses OAuth without using OpenID**, so I thought it would work. I wanted to get some confirmation. Although I said that because that's how I set it up, I still see the OpenID configured to be enabled because I can see the configurations from: https://gluu-srv.example.com/.well-known/openid-configuration

By Aliaksandr Samuseu staff 04 Oct 2016 at 3:17 p.m. CDT

Aliaksandr Samuseu gravatar
Franz, it seems to me like your approach is what creates most of your problems. You try to employ strictly regulated flows in a bit arbitrary way, while a first thing you should have probably done is try to run some basic flow strictly "by the book", and proceeding to experimenting with it only after your setup is confirmed to be in operational state. Have you sorted out that discrepancy in your settings/requests I mentioned [above](https://support.gluu.org/identity-management/getting-the-openid-oauth2-token-but-401-unauthorized-3310/#at15584)? And your request in [this post](https://support.gluu.org/identity-management/getting-the-openid-oauth2-token-but-401-unauthorized-3310/#at15595) again don't meet mandatory requirements, as your `scope` parameter misses "openid" value Please read OpenID specification for selected flow(s) carefully, as it's the only functionality that is *guaranteed* to work in Gluu, i.e. what is dictated by OpenID specs. Using it in other ways may be possible too, but until basic configuration is done right there is little sense in discussing it.

By Aliaksandr Samuseu staff 04 Oct 2016 at 3:21 p.m. CDT

Aliaksandr Samuseu gravatar
..actually, now checking your previous requests, I see they miss "openid" scope value too. I overlooked it before.

By Franz Noel Tanglao user 04 Oct 2016 at 3:44 p.m. CDT

Franz Noel Tanglao gravatar
I have previously tried using Oauth2 and Google Apps creating a client app, but not as an *Identity Provider*. So, it was easier experimenting with a real FQDN with HTTPS rather than on an internal dev site (I'm not sure if there is a difference in using demo.com and demo.dev). The openid and profile scope may only be optional as it just is a scope (from what I'm seeing). It doesn't seem to be indicated anywhere to use openid and profile as the scope. So I'm having a hard time figuring it out. It also seems like a basic GET with parameters on the first request. I'll try to reinstall my GLUU server (for testing purposes). That's actually my goal... to have the most basic setup and just get the token. However, if you're going to think about it... most applications are dependent on OAuth libraries, rather than basic HTTP GET or POST. I'll try to redo my test and come back. Thanks.

By Aliaksandr Samuseu staff 04 Oct 2016 at 4:16 p.m. CDT

Aliaksandr Samuseu gravatar
> The openid and profile scope may only be optional as it just is a scope (from what I'm seeing) If we are still talking about OpenID, "openid" value is not optional, at least by [OIDC core spec](http://openid.net/specs/openid-connect-core-1_0.html): > scope - REQUIRED. OpenID Connect requests MUST contain the openid scope value. If the openid scope value is not present, the behavior is entirely unspecified. That's why I recommend you to study it thoroughly. You have to, if you try to implement your own client app. I'm not sure Gluu supports *just* oauth2.0, may be Michael will be able to answer this. I would only recommend to stick to the spec as close as possible. OIDC is not the same as oauth2.0, just very similar.

By Franz Noel Tanglao user 04 Oct 2016 at 6:21 p.m. CDT

Franz Noel Tanglao gravatar
Adding to some information, I have tried to display all logs: DEBUG, TRACE, and INFO. I found out that according to this log, I don't see authentication process happening in the backend. Which could mean that although the `http://gluu-srv.example.com/.well-known/openid-configuration` displays the configuration, and there is a User Interface for OpenID, it doesn't mean that it is turned on (I was kinda puzzled). INFO | jvm 1 | 2016/10/04 16:11:33 | 2016-10-04 16:11:33,626 INFO [org.gluu.oxtrust.ldap.service.OrganizationService] Starting App version 2.4.4 INFO | jvm 1 | 2016/10/04 16:11:53 | 2016-10-04 16:11:53,492 DEBUG [org.jboss.seam.core.Manager] No stored conversation INFO | jvm 1 | 2016/10/04 16:11:53 | 2016-10-04 16:11:53,507 DEBUG [org.jboss.seam.core.Manager] Discarding conversation state: 35 INFO | jvm 1 | 2016/10/04 16:11:53 | 2016-10-04 16:11:53,649 DEBUG [org.jboss.seam.contexts.Lifecycle] Session started INFO | jvm 1 | 2016/10/04 16:11:53 | 2016-10-04 16:11:53,650 DEBUG [org.jboss.seam.core.Manager] No stored conversation INFO | jvm 1 | 2016/10/04 16:11:53 | 2016-10-04 16:11:53,652 DEBUG [org.jboss.seam.core.Manager] Discarding conversation state: 36 Comparing it with Admin login, it seems to be authenticating: INFO | jvm 1 | 2016/10/04 16:08:39 | 2016-10-04 16:08:39,687 INFO [org.gluu.oxtrust.action.Authenticator] user uid:admin INFO | jvm 1 | 2016/10/04 16:08:39 | 2016-10-04 16:08:39,708 INFO [org.gluu.oxtrust.action.Authenticator] Authenticating user 'admin' INFO | jvm 1 | 2016/10/04 16:08:39 | 2016-10-04 16:08:39,714 INFO [org.gluu.oxtrust.action.Authenticator] User 'admin' authenticated successfully INFO | jvm 1 | 2016/10/04 16:08:40 | 2016-10-04 16:08:40,834 INFO [org.gluu.oxtrust.ldap.service.OrganizationService] Starting App version 2.4.4 INFO | jvm 1 | 2016/10/04 16:08:55 | 2016-10-04 16:08:55,473 DEBUG [org.jboss.seam.contexts.Lifecycle] End of session, destroying contexts INFO | jvm 1 | 2016/10/04 16:08:55 | 2016-10-04 16:08:55,473 DEBUG [org.jboss.seam.contexts.Lifecycle] destroying conversation contexts: [] INFO | jvm 1 | 2016/10/04 16:08:55 | 2016-10-04 16:08:55,473 DEBUG [org.jboss.seam.contexts.Lifecycle] destroying session context INFO | jvm 1 | 2016/10/04 16:08:55 | 2016-10-04 16:08:55,473 DEBUG [org.jboss.seam.contexts.Lifecycle] End of session, destroying contexts INFO | jvm 1 | 2016/10/04 16:08:55 | 2016-10-04 16:08:55,473 DEBUG [org.jboss.seam.contexts.Lifecycle] destroying conversation contexts: [] INFO | jvm 1 | 2016/10/04 16:08:55 | 2016-10-04 16:08:55,473 DEBUG [org.jboss.seam.contexts.Lifecycle] destroying session context I'll go ahead and proceed with the re-installation, making sure that there is OpenID installed.

By Michael Schwartz Account Admin 04 Oct 2016 at 6:36 p.m. CDT

Michael Schwartz gravatar
You can't install the Gluu Server without oxAuth--it's required. So there is no way to install the Gluu Server without OpenID Connect, as it's the basis for everything. I think the problem is that you are writing a low level client, and you have not read the OpenID Connect specs carefully. If you want to continue, you should at least read the [OpenID Connect implicit client implementers guide](http://openid.net/specs/openid-connect-implicit-1_0.html) and probably the [Core Spec](http://openid.net/specs/openid-connect-core-1_0.html) too.

By Franz Noel Tanglao user 04 Oct 2016 at 7:10 p.m. CDT

Franz Noel Tanglao gravatar
Here are the authentication protocols that I have setup: - SAML - not enabled - Open ID - not enabled - oxAuth - enabled - oxTrust - enabled - LDAP - enabled - Apache -enabled I have previously logged this information while installation. Also, before I asked the question in this thread, I have been able to view the previous questions, the documentation in GLUU, and the OpenID standards in using code and authorize_code (from those questions). My problem is not about following the flow, because I am receiving the code, state, and session_state. However, I'm not getting the **token**, wherein it is just basic `POST` with extra `HEADERS`. In the previous logs, it does not show that **Song App** was submitted nor recognized by `org.jboss.seam.contexts.Lifecycle` or `org.gluu.oxtrust.action.Authenticator` Some questions: Is there anyway to enable OpenID while it is running on Tomcat? Before I reinstall?

By Michael Schwartz Account Admin 04 Oct 2016 at 7:16 p.m. CDT

Michael Schwartz gravatar
I have no idea what you are talking about. How can you not have Open ID not enabled? Where does it say that? oxAuth == OpenID Connect. I guarantee you that why you are not successful is because you have 1. not registered the client properly 2. are not making the correct authorize request 3. are not making the correct token request Please read the basic client implementers guide as I recommended, and post a more specific question when you've done your homework.

By Franz Noel Tanglao user 04 Oct 2016 at 7:26 p.m. CDT

Franz Noel Tanglao gravatar
When installing GLUU Server in CentOS 7 following this document: https://gluu.org/docs/deployment/centos7/ It will prompt you with the feature GLUU will install in your system. Then it will prompt if you want that feature. It was just a simple Y/N. Caps for "N" or "Y" means recommended installation. OpenID was not recommended with a small "y". It says, "y/N". So, I chose "N". So, I made sure to write in my notes that OpenID is not enabled. However, oxAuth was enabled, which was probably the code for OAuth or OAuth2, but not OpenID (I haven't dug in much).

By Michael Schwartz Account Admin 04 Oct 2016 at 7:34 p.m. CDT

Michael Schwartz gravatar
I'd love to see a screenshot of that. I wonder if you mean oxAuth RP, which is an optional web interface for OpenID Connect, that is not at all required, and just a convenience (in fact you could run oxAuth RP from any server). Per my previous comment, your problem is clearly that you are not following the openid connect protocol properly, for which the Gluu Server has passed [all the conformance profiles](http://openid.net/certification/)

By Franz Noel Tanglao user 04 Oct 2016 at 8:59 p.m. CDT

Franz Noel Tanglao gravatar
I'll give you a beer no matter what happens if I win or lose (for the support). But I remember when I was creating an application, a `scope` is something that you want to access after the token has been given. So, I don't think that `openid` would matter if it is in the scope or not. My boss doesn't want me to reinstall the test server because she wants me to learn how to turn on and turn off features. Also, the error is `invalid_client`. So it wouldn't matter how I would send the second request, just as long as I follow proper requests of sending the inum or client_id (I believe so). And I've tested it in different ways (if you're only thinking that I did it one way... both client and server side coding, and placing client_ids and secret_keys in different ways). Tomorrow, I'll send the screenshot.

By Michael Schwartz Account Admin 04 Oct 2016 at 10:17 p.m. CDT

Michael Schwartz gravatar
Support is not a place to get training. Read the [Implicit Client Implementers Guide](http://openid.net/specs/openid-connect-implicit-1_0.html) Read the [core spec](http://openid.net/specs/openid-connect-core-1_0.html). Then when you have a decent understand of the basics, then please open a new issue and ask specific questions about how to configure the OP and how to write your client code. Until then, this issue is closed. The goal of the support forum is to provide help on the Gluu Server where the specs or documentation is unclear. It is not a substitute for reading the specs and docs.

By Michael Schwartz Account Admin 06 Oct 2016 at 9:24 a.m. CDT

Michael Schwartz gravatar
After you're done reading the implicit implementers guide, you should read this article from Nat Sakimura: [Making a Javascript OpenID Connect Client in 4 steps](https://nat.sakimura.org/2014/12/10/making-a-javascript-openid-connect-client/) [Code](https://www.sakimura.org/test/openidconnect.js)

By Franz Noel Tanglao user 06 Oct 2016 at 4:30 p.m. CDT

Franz Noel Tanglao gravatar
I have to admit that I was reading **OpenID** and **Oauth2** rather than **OpenID Connect** documentation by mistake for a really long time, and I was confused in both. The documentation you gave made me realize that I really need `openid` scope. Currently, I'm using **openidconnect** JavaScript library, and `implicit` grant_type, but it seems like I have a `badstate` retrieving the `state` value. I may have to resort in finding the most simple and correct implicit library just like it, or debug it. However, it seems like the documentation only needs `id_token` to be stored in the cookie to handle the session. Thanks. **Other matters:** On a side note (not related to this thread), you were right about OpenID Connect not being in the installation. Also, I used **/install/community-edition-setup/setup.py** to try to disable/enable some features, and I couldn't login with the admin account, because the LDAP server crashed. However, I was able to make it work again when I reinstalled everything.

By Michael Schwartz Account Admin 06 Oct 2016 at 5:57 p.m. CDT

Michael Schwartz gravatar
`state` is set by the client and is returned unmodified by the server. It's a way for the client to know that the response is not a random response from an attacker.

By Franz Noel Tanglao user 06 Oct 2016 at 7:14 p.m. CDT

Franz Noel Tanglao gravatar
Yes, I found out that the openconnectid JavaScript library retrieves the first instance of `state=` (a bug) which will mean that it will also retrieve the first instance `session_state=`. I modified the openidconnect JavaScript code to accept `&state=` and `?state=` to make sure that it will only compare the `state` value.

By Michael Schwartz Account Admin 06 Oct 2016 at 7:26 p.m. CDT

Michael Schwartz gravatar
We just forked this code to a new [github project](https://github.com/GluuFederation/openid-implicit-client) Feel free to submit a pull request if you think its a bug.