Using OpenID Connect to authenticate users
Hello all, I want to use OpenID Connect to authenticate my users before gaining access to one of my application. I want to use my bigip as OpenID Provider (ie: the entity that authenticate the users) . My issue is the following: The OpendID provider (my bigip) never provides me with a ID Token. All I have is an “Access Token” and a “Refresh Token” but no “ID Token”. Below is a description of my lab: resource owner: ip address 10.10.255.1 bigip OpenID Provider: virtual server ip 10.10.255.221 (see below for the access policy) *The agents are left with their default values. Client: I user openid debugger (https://oidcdebugger.com/) in order to request the authorization code. Then I request the Tokens using an html code. I do the following for testing : I request the authorization code from the authorization server (ie my virtual server) . For this I use openID Connect debugger to construct the request for me. Here is the request that I send : ? client_id=e1111098ccff5f81859f9fc83eaa000c29267803efc0bb5b & redirect_uri=https://oidcdebugger.com/debug & scope=openid myscope & response_type=code & response_mode=form_post & state=toto & nonce=7r8saarltr After sending this request I enter my credentials (in the logon agent), I click on authorize then the virtual server correctly redirects me to: https://oidcdebugger.com/debug code=cae85f6fd33c6b27f56f536b6fd9af2ca0fc78e69ac3d13799533c143b38b4ac&state=toto” I now have a correct authorization code that I can exchange for an “access token” AND a “ID Token” . I then send a POST to get the access and ID Tokens using the following HTML code : *note the presence of the “openid” in the scope parameter. However, this is what I get from the authorization server (see in the comment) : -> I have No “ID TOKEN” ☹ Could you please help me configure my access policy so that it supports OpenID Connect and sends me an “ID Token” ??
Authenticate user of native mobile app with OpenId Connect
Does F5 Big IP Access Manager support mobile apps authenticating over OpenId Connect with custom URI redirect_uri? Our native mobile app (iOS and Android) authenticates the user using the Authorization Code Grant flow. How it Works. Our redirect_uri (ie callback uri) is: com.mckesson.wfm.ansos2go://signin We are a software vendor in the Healthcare domain. Our customer who uses F5 Big IP says that this URI is considered invalid by F5 when configuring the OpenId Connect Service Provider. Is that true? If so, how do native mobile app developers perform OIDC authentication with F5? Thanks, Scott UPDATE: I got word from my customer that they set up a rewrite policy, so they could enter the redirect_uri as https:/com.mckesson.wfm.ansos2go://signin. Then, they strip off the https:// in the response to the initial 'authorize' call. This is NUTS! Why does F5 Big IP Access Manager require redirect_uri to be https://...? This totally breaks the OpenId Connect specification which says "The Redirection URI MAY use an alternate scheme, such as one that is intended to identify a callback into a native application." https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint
APM OIDC debug logging is somehow verbose but not where it should - RFE
While I was configuring and testing an APM Access policy for an OIDC integration with Entra ID, I was seeing some backchannel errors logged (debug level) some HTTP error 400. The whole logging is quite verbose, but here, not very useful: [...] OAuth Client: failed for server '/Common/entraid_test' using 'authorization_code' grant type (client_id=xxxxxxxxxxxxxx), error: HTTP error 400, Session variable 'session.oauth.client./Common/entra_front_act_oauth_client_ag.errMsg' set to 'HTTP error 400, ' Session variable 'session.oauth.client./Common/entraid_test.errMsg' set to 'HTTP error 400, ' Session variable 'session.oauth.client.last.errMsg' set to 'HTTP error 400, ' So, tcpdump was required to see what exactly the error was in the returned JSON payload from Entra ID. I've got a new RFE from F5 support => (Bug alias 2229965) [RFE] Add extra verbosity for the debug-level logging for OIDC backchannel connection Don't hesitate to open a support case to get it bound to that RFE, the more we are the higher priority will be assigned to implement it (hopefully). 😀 Alexandre
