First let me answer your question right away, but then I’ll go back to architectural decisions.
Each tenant has its own set of public/private key to generate and validate the token signature, and the
iss (issuer) claim on JWT tokens will vary depending on the tenant. This means, effectively, that tokens generated from different tenants are completely independent.
Now, nothing prevents you from building a server-side API authorized by JWT tokens that looks for the
iss claim and, based on it, fetches the matching public key to validate the signature. Some of the Jwt Bearer authentication SDKs (like ASP.Net’s) allows you to easily configure support for more than one token issuer, but it’s definitely not a common scenario.
Which leads me to the architectural decisions talk. As I said before, having more than one token issuer for an API would be really uncommon. Thinking of a widely know API such as the Google Docs API. You might have a third-party app made by Acme.com that wants to use the API, but the issuer of tokens is Google, and the authentication comes from Google Accounts. When requesting a token for the Google Docs API, the login page is branded by Google, with a mention of the application that is requesting the token (e.g. “Acme”). The login page should be a reflection of the directory where the user authenticates, that’s why you see Google branding regardless of the application that is requesting the token. It also helps the user know that the Google Account is being used to authenticate.
So, in your case, it might help thinking who really authorizes applications to access the API, and that would be the tenant where the API is defined. That authorization server might have multiple options to authenticate the users (those would be the connections). You could have social connections and a database connection for email/pwd authentication.
Will you have just these two subdomains? Do you want to keep identities completely isolated? If so, the solution might be using two different database connections, one per subdomain. The hosted login page could pick the connection name and change the style accordingly (as in “Authenticate as a partner” or “Authenticate as a user”).
Sorry if the answer is light on details, but it’s difficult to go deeper without the whole picture.