Different projects one sprint

A board should give the Developers transparency over their progress to achieving a Done Increment. That's the commitment they're making. Let them experiment and figure out how to best structure their workflow, define its policies, and to understand their commitment point.

Whatever they choose, they'll run into problems if they're trying to push work through. Scrum, in common with any lean or agile way-of-working, is based on pull.

It is a good idea to have one Jira board for each product since you should have one backlog for each PRODUCT.

In Scrum, "project" is not precisely defined. Although they may be considered separate projects, multiple teams working on the same product should share the same backlog.

Then, you should figure out a means to divide or share the same backlog list of "issues" (as Jira refers to them) graphically. You can do this by making it accessible to several teams or by somehow dividing different teams using a at one template

Always a Jira project for a scrum product.

and one board per product

and one sprint per product.

and one pb per product

If for some obscure reason you need a board for several projects/products you can do this. (technically speaking)

As @Ian said a Scrum is a pull system. The team needs to be able to pull from a prioritised backlog. The team can then decide how best to display the sprint items. 

Starting with the backlog, I have somewhat of a different view. Scrum works on a prioritised backlog, and if there are multiple backlogs, then I think the priority will be muddled. 

The Scrum Guide talks about a product per backlog, but we are trying to make things work in a multi product environment. I lean towards defining a product/portfolio consisting of multiple "sub-products", then group all items on one backlog. From a backlog perspective a backlog item is just an item. The important thing is to have a single prioritised backlog to pull from. Use a label or something on Jira to differentiate between products. 

You can't change the definition of product that easily.

with 1 product you have One backlog product and all events for this product and one stakeholder for this product. You have 1 sprint backlog per team.

Your sub-product is like a product ? what is the differerence ? is it just because they look alike?

Similar doesn't mean the same.

if you need to use a label to separate your tickets in sub-product, you're cheating because you're dealing with several products.

In short, by thinking you're simplifying by distorting the definition of a product, you're adding complexity to your management...are you going to do sprint reviews for each sub-product? if not, what are you going to lose, what do you really think you're going to gain? are you going to do retrospective for each sub-product? if not, do you think it's useless? do you really think that each "product" renamed into sub-products will all have the same problems? isn't that a little too optimistic? Are you looking for automation in an exaggerated way, forgetting the relationship with the customer/team? How big will your backlog if you mix several products, even if they're called sub-products, in the same backlog? 

Is it that it is the same pool of developers who are responsible for multiple products?

I'm sorry, but I'm confirming my opinion and my experience. Even if it's the same group of devs, it's a fake good idea. putting everything in the same project means trying to reduce the number of events, thinking that it will increase productivity, but it will compromise quality and increase delays. Jira isn't designed for multi-product Scrum in a single project, unless there are major complications. In theory, you can always do everything...

Otherwise, you can use empiricism to test things out for yourself... experience will help you understand...