@bradymiller
Lax is working for me today from chrome using the origin https://openidconnect.net/ ! so go figure. The way to tell is if the consent scopes don't show in consent dialog. Still don't trust yet however, i'm going to pull this branch, test using it while I finish session persist. Having a little problem here of getting the encrypted code for lookup identifier because persistNewAuthCode() is the entity before encryption. Only way is to parse it out of the redirect GET query. Easy enough but seems like a hack to me so, still poking around for a better way to id the session cache.

Do you want me to just pull/push from/to this PR or do you want dueling PRs?

Also, to test the id/access token to see what claims/scopes are set use https://jwt.io/ you can also test the signature there by pasting the public key that was used to generate the private key of token.

• will be pulling userId and clientRole from oauth_client table or may repurpose columns. This will also remove those claims

@sjpadgett , Regarding PR, just do whatever is easiest for you (use my PR or your own PR). I'm happy to adapt my PR whenever needed.

Just let me know if you will be using my PR (then I'll hold off on pushing anything to it until you give the all clear :) ).

Another option is to just bring this PR into codebase (if so, would just take me an hour or so to do a extensive code review to make sure i didn't do anything stupid :) ).

Another option is to just bring this PR into codebase

Will break master until I fix session which i'm about an hour from finishing that then testing. I can just push to you then put in master.

Almost done. I have working but I think I should encrypt session data store in trusted user. You want to do or me, I don't care?

happy to do that. lets see what it is storing first.

{"site_id":"default","enable_database_connection_pooling":"1","nonce":"b313b048372f0f5aa1b32a5d5e899b3f","csrf":"d6a807c60136440c3c0e46f98162bb47","scopes":"openid api:fhir email","client_id":"kbyuFDidLLm280LIwVFiazOqjO3ty","user_id":"91e65743-aa8c-4a7e-a183-706912c92436","user_role":"users","persist_login":0}

I think we'll be okay. I pulled sensitive unneeded session vars. I'll push to you as soon as I get organized

Hope I got it. Seems to work but limited testing so you can move on but here is an access token decode;

{
  "aud": "kbyuFDidLLm280LIwVFiazOqjO3ty8KH",
  "jti": "e0a274c05d57a75267d22cb509aade5e4f732bbd502f7d7b3d85a0ba48058e874e47bb34d2846772",
  "iat": 1605474673,
  "nbf": 1605474673,
  "exp": 1605478273,
  "sub": "91e65743-aa8c-4a7e-a183-706912c92436",
  "scopes": [
    "openid",
    "profile",
    "email",
    "phone",
    "address",
    "nonce",
    "site:default",
    "user_role:users"
  ]
}

Guess I could have did one with api scopes but anyway, there it is.

this is testing well and code looks sane. bringing in!