Question: Should be a fairly simple problem but it's one that's had me stumped for ages now. I want to write a regular expression that matches a string of any length of any characters, followed by 3 - 4 uppercase letters or numbers as long as that string doesn't start with a 'D', followed by the string 'ABCD', followed by a '.', followed by three digits. So it would look something like this:

```
r"(.*)(?<!D[A-Z0-9]{3,4})(ABCD.\d\d\d)"

```

The second group is the one I want to capture/ extract and it's the one I can't get right. It needs be greedy matching (i.e. try to match 4 uppercase letters as long as the first one isn't a D, and the fourth character isn't the A from the 'ABCD' string). so if I ran it against the the following strings:

```
"a \ranDom \ str1ng\DADDABCD.123"
"a diff3r3nt\ranD0m \ str1ng\ DCDZAABCD.123"
"a 3rd\r4ndom \ str1nng\ ADDABCD.123"
"a\ diff3r3nt\ranD0m \ str1ng\CDZAABCD.123"
"a\ diff3r3nt\ranD0m \ str1ng\CDZAABCD-2.123"

```

It would return:

```
None
None
ADD
CDZA
None

```

Answer: 
Sending an authentication request via a redirect to the Provider including `prompt=none` addresses this use case: it will silently login and return new tokens if there's an ongoing SSO session at the Provider, it will return an error code `login_required` if not.

Notice there will never be explicit user interaction in both cases so this is convenient (and meant) to run in an hidden iframe.
**LOGGED IN STATE**

An OAuth client is most commonly a UI application with multiple users. Each user's logged in state is represented by an Authorization Server session cookie that neither the application or user have access to:

* The Authorization Server (AS) issues an SSO cookie, to be stored in the system browser for the AS domain
* Both Web UIs and Native UIs send it implicitly on subsequent requests, when they invoke the system browser

**AUTHORIZATION REDIRECTS**

When an OAuth UI redirects the user, it is generally unknown whether:

* The user will be prompted to login
* The user will be signed in silently (eg the user could have signed in to another app)

For a Web UI it is possible to send an authorization redirect on a hidden iframe with a **prompt=none** parameter. If the user needs to sign in a **login\_required** error code will be returned. See my [Silent Token Renewal Page](https://authguidance.com/2017/10/24/user-sessions-and-token-renewal/) for further details.

This is not fully reliable however, and has some [browser issues in 2020](https://authguidance.com/2019/09/09/spa-token-renewal-challenges/). Also it may be unsuitable if you are using a different type of client.

**FEDERATED LOGINS**

In some setups the AS redirects further to an Identity Provider (IDP), and the user's login state is further influenced by an IDP session cookie.

There is no way for an app to get hold of the user's IDP login state, since the app only ever interacts with the AS.

**IS THERE A USABILITY PROBLEM?**

If so, post back and we can discuss further ...