TL;DR
You probably don't want to hear this, but the developer is probably right about your lack of experience, although based on what you've said they are addressing it in a very unconstructive way. From your own description, you clearly lack effective authority, influence, and delineation of roles on your project, making this more a question of fitness for the roles each of you is playing rather than one with a straightforward answer.
The goal of my answer isn't to be unkind. The goal is to force you to take a hard look at your skills and capabilities, and to reflect honestly on whether you have the ability to salvage the situation without resorting to organizational fiat that (I strongly suspect) is not fully warranted in this situation.
In other words, you will need to look in the mirror to find concrete solutions to this specific set of problems. Take inventory of your skills and abilities, collaborate with your management team, and (if possible) work with the team to implement any necessary changes.
"There is no magic bullet."
Analysis
The number of years of experience you have is less important than your ability to fulfill the role you're in. Let's take a look at some of the things you've said.
A seasoned developer is challenging my authority and expertise[.]
Authority doesn't really come from titles. Authority must be delegated from the organization's leadership team, and ultimately that authority must be backed by senior management. If they aren't actively backing your "authority," then you don't actually have any. This isn't uncommon in project management, which is why influence is often the most important skill in the profession.
I am quite new to project management... I feel embarrassed, shy, and inexperienced...even though I have expertise as a PM and as a developer.
You have several problems here. These include a lack of sufficient self-confidence to effectively exerting interpersonal influence, and a mismatch between your own stated lack of experience and your level of assumed "expertise" in project management and software development. Experience is about exposure and time, while expertise is about depth of skill. Based on the nature of the question you're asking, I would suspect you really do lack sufficient expertise for the role you're in, whether or not you have sufficient experience.
You may also lack the right personality for the role you're currently in. While it's true that everyone needs to build confidence through experience, personality and drive play a part too. That isn't to say that introverts or people with a normal level of imposter syndrome can't be successful in such roles. People who are shy to the point that they are unable to project influence, or resolve interpersonal or structural conflicts related to their roles, can find it difficult to be successful in a people-driven profession such as project management.
My duty is to write code only. The rest should be provided by you.
Setting aside the developer's lack of constructive soft skills, your inability to respond to this statement from the developer means that you have failed to effectively define the roles within the project team. While you haven't explained what you and the developer are clashing over, it's quite clear that the roles of the development team and the project manager have not been clearly defined, and (much more importantly) you aren't able to clearly articulate them.
On a closely related note, you haven't expressed any sort of value proposition here. The developer is clearly telling you that he doesn't see the value in your role. If you can't explain how your role is adding value to the project either (other than providing an "authority" you don't have or can't project), how can you expect the rest of the project team to see it?
Options
You have a number of options. Not all of them will fit your situation, and a canonical list of action items isn't really possible. However, there are certainly broad classes of things you can do.
If the developer is right, and you do lack sufficient knowledge and expertise to lead the project successfully, be honest with your management team.
This is probably the least pleasant option, but it needs to be said. If you can't succeed in your current role, don't set yourself up for failure by trying to force a fit. Either find a project within the organization that fits your personality and current skill set better, or gain additional training and experience outside of your current role before attempting to dive into a similar role again.
If the developer is simply misguided, then you need to step up to define the roles and chains of authority that govern the project team.
Refer to the project charter or other governance documents to clarify roles and responsibilities. If necessary, inspect-and-adapt them. If the roles and responsibilities are both clear and useful as currently written, then you need to ensure you have buy-in from both the team and senior management.
If you lack authority, use influence or pass the buck.
You can't exercise authority that hasn't been delegated. Either get explicit authority for your role from your project charter or from senior management. If you are given responsibility without authority, then you need to rely on personal influence to get things done. If you can't exert sufficient influence to resolve issues, then pass issues upstream to senior management. Ultimately, any authority you may have comes from them, and the success or failure of the project is their responsibility.
Rely on the framework, or implement one if needed.
If your project lacks rigor, problems arise. Defining roles, or exerting influence and authority, are important; however, they are only means to an end. Achieving successful outcomes is the real goal here. If your current team needs better roles, better processes, or more useful project controls, your job is to implement them within the scope of your authority (if any), or to suggest necessary changes to senior management for their consideration.
Change what you can; accept what you can't or won't change.
If the problem is you, change your approach, learn new skills, or change your role. If the problem is the developer, improve your collaboration and increase buy-in, or work with management to get him replaced. If you can't or won't do any of those things, then accept things as they are, prepare for inevitable friction and likely failure.
Whatever you do, you also need to accept risk. This includes the risks of making personal, team, project, or organizational changes, as well as the risks of failure. The risk of doing nothing in a bad situation is usually higher than the risk of doing something with a constructive goal, but the risk assessment must be yours. Either way, you must accept the consequences, both positive and negative, of the choices you make. You aren't responsible for other people's choices, but you are always responsible for your own.
The specific elements, choices, people, and risks involved with each of these general options will vary widely. One size does not fit all. However, you need to demonstrate active agency in the process. Waiting for things to change on their own, or thinking that there's a simple answer that can "fix" your problem, will not get you anywhere good.
Take stock of the situation. Inventory your skills. Be honest about your capabilities and available options. Then make the best choices you can, ideally in collaboration with members of your organization who can help you implement any necessary changes.
